[02:36:42] Change on 12mediawiki a page OAuth was modified, changed by Shirayuki link https://www.mediawiki.org/w/index.php?diff=1327534 edit summary: noinclude [06:38:20] PROBLEM - Puppet failure on tools-exec-07 is CRITICAL: CRITICAL: 44.44% of data above the critical threshold [0.0] [06:46:40] PROBLEM - Puppet failure on tools-exec-cyberbot is CRITICAL: CRITICAL: 55.56% of data above the critical threshold [0.0] [07:03:18] RECOVERY - Puppet failure on tools-exec-07 is OK: OK: Less than 1.00% above the threshold [0.0] [07:11:45] RECOVERY - Puppet failure on tools-exec-cyberbot is OK: OK: Less than 1.00% above the threshold [0.0] [07:42:49] !log [07:42:49] Message missing. Nothing logged. [07:42:59] !log tools increased RAM and Cores quota for tools [07:43:03] Logged the message, Master [08:19:45] PROBLEM - Puppet failure on tools-uwsgi-01 is CRITICAL: CRITICAL: 14.29% of data above the critical threshold [0.0] [08:24:45] RECOVERY - Puppet failure on tools-uwsgi-01 is OK: OK: Less than 1.00% above the threshold [0.0] [08:36:46] PROBLEM - Puppet failure on tools-uwsgi-01 is CRITICAL: CRITICAL: 66.67% of data above the critical threshold [0.0] [09:26:47] RECOVERY - Puppet failure on tools-uwsgi-01 is OK: OK: Less than 1.00% above the threshold [0.0] [09:52:42] 3Labs-Team, operations: labs VMs install with outdated packages - https://phabricator.wikimedia.org/T85024#939411 (10fgiunchedi) p:5Triage>3Normal what's "os installation" in labs context? I was thinking about "when a vm first gets boot up" or in other words "provisioned" as opposed to when the image is firs... [10:12:36] 3Labs-Team, operations: facter: VM detection incorrect in labs - https://phabricator.wikimedia.org/T78813#939483 (10fgiunchedi) p:5Triage>3Low indeed, the standard facter detection without virt-what relies on /proc/cpuinfo containing magic strings ``` def self.kvm? txt = if FileTest.exists?("/proc/cpu... [10:14:18] 3Labs-Team, operations: Make labs salt use instance names than ids - https://phabricator.wikimedia.org/T1154#939486 (10fgiunchedi) p:5Triage>3Low [11:21:23] valhallasw`cloud: legoktm YESSS, running uwsgi https://tools.wmflabs.org/wp-signpost/feed [11:25:01] so far at uwsgi --plugin router_rewrite --plugin python --http-socket :9999 --chdir=/data/project/wp-signpost/code/signpost/WPSignpost/api/ --wsgi-file=/data/project/wp-signpost/code/signpost/WPSignpost/api/app.py --virtualenv=/data/project/wp-signpost/code/signpost/ --callable=app --master --route='/wp-signpost/(.*) rewrite:/$1'^C [11:25:08] now let’s run this on the grrrrrriiiiiiddddd [11:27:59] YuviPanda: you mean 'not running'? :-p [11:28:14] YuviPanda: because it looks distinctly brooooken :-p [11:28:27] valhallasw`cloud: yeah, beacuse I killed it :) [11:28:30] :-p [11:29:47] valhallasw`cloud: also, uwsgi does redirects too9 https://github.com/unbit/uwsgi-docs/blob/master/InternalRouting.rst [11:29:52] valhallasw`cloud: and supports like, a fuckton of languages [11:29:58] yeah [11:30:18] valhallasw`cloud: plus websockets! [11:30:28] then again, yet another configuration thing to learn :< [11:30:46] https://github.com/unbit/uwsgi-docs/blob/master/InternalRouting.rst#the-first-example [11:30:49] :| [11:30:50] well, the defaults should just work. [11:30:54] mostly [11:31:19] default is to look for callable app in app.py in ~/public_html [11:31:22] with a virtualenv in ~ [11:31:25] does that make sense? [11:31:40] YuviPanda: no [11:31:43] YuviPanda: don't. [11:31:57] why not [11:31:59] YuviPanda: everything in public_html should be considered readable to public [11:32:20] YuviPanda: which is probably *not* what most people want their app.py to do [11:32:24] to be* [11:32:25] hmm [11:32:26] that is true [11:32:28] or expect, at least [11:32:40] uwsgi_bin? [11:32:46] ewww [11:32:49] eeeewwwwwwwwwww [11:33:13] or just ~/.uwsgi/venv and ~/.uwsgi/src ? [11:33:22] .uwsgi? [11:33:26] seriously? [11:33:27] why [11:33:39] brainstorming. [11:33:45] oh, that [11:33:46] sorry. [11:33:47] hmm [11:33:49] :D [11:33:52] how about just uwsgi/? [11:33:57] yeah, that works [11:34:04] or even better, python_www? [11:34:13] but you just said it was not just python :o [11:34:18] hmm [11:34:19] true [11:34:20] I mean [11:34:21] *confused* [11:34:25] (although venv is pretty python) [11:34:29] right now we don’t have a ny non-python plugins for uwsgi installed [11:34:32] *non [11:34:41] but it can run anything from perl to Java to Mono to Lua... [11:34:46] to Ruby [11:35:16] ~/uwsgi-python/...? [11:36:19] that makes sense, yeah [11:36:26] and over time, uwsgi-perl and maybe uwsgi-lua [11:37:12] valhallasw`cloud: HAHAHAHAH http://uwsgi-docs.readthedocs.org/en/latest/PHP.html [11:37:12] :D [11:37:15] man, that’s evil [12:39:37] valhallasw`cloud: alright, I’m going to make it be ~/uwsgi-python [12:39:58] valhallasw`cloud: only if it exists, of course. if not it shall error. [12:40:10] <_joe_> !log deployment-prep upgrading HHVM to the latest version [12:40:15] Logged the message, Master [12:41:37] _joe_: btw, I’m setting up uwsgi now, without lighty. I know how it works a bit better, so thought I’ll start there. [12:41:58] * YuviPanda it has definitely gained a lot of features since I last saw it. [12:42:03] <_joe_> YuviPanda: ok it seems a good idea [12:42:15] <_joe_> uwsgi is *so* nicke [12:42:21] nicke? [12:42:31] <_joe_> -k [12:42:43] <_joe_> I have an horrible lag today, ~ 3 seconds [13:11:53] valhallasw`cloud: hmm, how about www/python? [13:11:59] uwsg-python seems a bit too implementation specific [13:22:43] YuviPanda: :like: [13:22:50] 👍, I mean [13:23:56] hehe [13:26:48] YuviPanda: and then www/python/src and www/python/venv ? [13:27:04] valhallasw`cloud: hmm, that sounds saneish. [13:27:22] valhallasw`cloud: and in the future we can follow similar structures for other appservers too [13:27:28] *nod* [13:27:56] valhallasw`cloud: all of this is overridable, of course. [13:32:18] valhallasw`cloud: now we just need to document all of this properly... [13:32:51] valhallasw`cloud: and then we can get the 'toollabs starter kit!' going at some point :) [14:02:50] valhallasw`cloud: jesus man, this is frustrating... [14:03:02] valhallasw`cloud: installing things into same venv from precise and trusty corrupts venv. [14:03:12] YuviPanda: ...:| [14:03:20] YuviPanda: that's super weird [14:03:23] yup [14:03:27] YuviPanda: compiled stuff? [14:03:35] valhallasw`cloud: no, just anything, really. [14:03:35] YuviPanda: maybe a different libc version or something [14:03:53] YuviPanda: wtf?! that shouldn't happen, and it doesn't happen for wikibugs2, I think? [14:04:08] YuviPanda: I'm surprised the same venv runs, though [14:04:12] valhallasw`cloud: it did happen to wikibugs at least once, when I was hacking on it [14:04:13] Oh god I can't wait for the holidays to end. [14:04:14] as the py3 versions are different [14:04:20] or is this py2? [14:04:57] valhallasw`cloud: oh, py2. I don't think py3 has this problem. [14:05:00] Coren: oooh? [14:05:08] YuviPanda: dunno? super weird. [14:05:19] Meh, I just don't like the family obligations. [14:05:21] YuviPanda: basically, the venv should just Not Work(TM) on the other host [14:05:58] Coren: oh, *that*. Yeah, I've succeded in making my sim unreachable for the last month, yay [14:07:50] Coren: do we have a set range in which tool uids will be? [14:08:00] Coren: I'm thinking of just letting every tool listen in on its own uid as port :) [14:08:32] Young nyn T [14:08:39] YuviPanda: There is no range per se no, and only a lower bound full of exceptions. [14:09:04] It's ">5000 except for all the ones that aren't" [14:10:01] ah, hmm. that probably will be a bit lossy... [14:17:19] Coren: hmm, so other than the exceptions, do you foresee any other issue with just using the uid for this? [14:18:41] I still fail to see any advantage to it, though I don't see any particular issue either. [14:19:38] You still have to register the IP if nothing else, so why not register both as we currently do and guarantee no collision? [14:21:13] Coren: I *am* registering both with *proxylistener* [14:21:17] Coren: this just kills portgranter [14:22:24] But what does it gain? [14:22:39] Coren: removes a moving part with no reduction in functionality? [14:23:08] a socket network call that requires portgranter to be up is instead replaced with os.getuid() [14:24:05] You mean, except for the automatic deregistration when the process dies. [14:24:20] Coren: that has always been handled by proxylistener as well [14:25:17] Wait, so you'll keep the connection to proxylistener open as before? [14:25:30] Coren: yup. only removing portgranter from the equation. [14:25:34] one step at a time, etc. [14:26:17] Coren: well, porgranter and lighty. [14:26:45] Coren: and no portgrabber either - just a wrapper script, since it already knows what port to use (just getuid()) [14:27:19] Heh. I really, *really* don't get why you're insisting on removing it from the equation as it has always worked fine. Not having lightly in place when you only have an *cgi running is a good thing I just don't understand why you see portgranter as an obstacle in any way. [14:28:23] Coren: I'm just removing excess parts that aren't required at all. Making things as simple as possible. [14:28:30] I *like* having fine grained control on what port gets used, and portgranter has the ability to also manipulate firewall rules (which we don't do not, but that was always part of the intended use) [14:28:48] Coren: portgranter right now is just a super simple hashtable / set, and literally nothing more [14:29:10] Coren: YAGNI, etc :) [14:29:41] Coren: I am not seeing portgranter as an obsctacle, just... something that's unnecessary? I'm not removing it from lighty etc yet, just not using it in the new webservices types. [14:31:02] yo [14:31:14] do we have asp.net support on lighty? [14:31:36] And that is what I am opposed to. I want port allocation to be uniform and to use the same mechanism regardless of what mechanism you use. Also, while we're not using the capability now, there's nothing that prevents us from allocating more than one dynamic port at need which any fixed port numbering scheme doesn't allow for. [14:32:25] Coren: again, YAGNI. we can add a port/services directory when we find some need for it. none of this is set in stone. [14:33:06] leloiandudu: heya! [14:33:26] leloiandudu: we do have Mono on toollabs, and I guess you can hack up fcgi support for it... [14:33:31] leloiandudu: nobody has done it yet afaik, though. [14:34:34] I found a tutorial here: http://www.mono-project.com/docs/web/fastcgi/lighttpd/ but it seems we are lacking fastcgi-mono-server [14:34:39] Coren: uh, can you help me create a new queue? I'm not sure I've done *that* [14:34:39] could we install it? [14:35:24] leloiandudu: sure. can you open a bug report on phabricator.wikimedia.org so we can track it properly? I will get it done in a few minutes. [14:35:24] Dude stop saying YAGNI - it's a horrid principle that never ever leads to good results. It's design with a blindfold at best, foisting trouble on your successors at worse. [14:35:24] here is how to install it: http://www.mono-project.com/docs/web/fastcgi/#installation-basics [14:35:57] YuviPanda: Sure. Not very hard, especially since (I'm guessing) you want to do a new webservice queue? [14:36:06] Coren: yup, I DO> [14:36:14] stupid shift stuck again. [14:37:22] Coren: I'm going to disagree and say less moving parts the better. It's *not* design with blindfold, it is 'if this part can be thrown away without any reduction in functionality, do throw it away'. [14:37:24] ok, thank you guys! i'll open an issue on phabricator then [14:37:37] Coren: plus, I'm on a mandate from mark to reduce the total amount of perl in our repositories as well :) [14:37:54] leloiandudu: cool! :) [14:38:11] Coren: this is the uwsgi web queue, not hhvm. [14:38:28] Coren: experimenting with the uwsgi queue since I know more about uwsgi than hhvm atm, and would be easier to adapt that wayl. [14:38:29] *way [14:41:55] 3Tool-Labs: Add support for ASP.NET on Tool Labs - https://phabricator.wikimedia.org/T85142#939835 (10Leloiandudu) 3NEW [14:41:57] 5 [14:42:13] I hope I did everything right; https://phabricator.wikimedia.org/T85142 [14:42:33] ok, bot is faster tham me :) [14:52:13] 3Tool-Labs: Add support for ASP.NET on Tool Labs - https://phabricator.wikimedia.org/T85142#939843 (10yuvipanda) `mono-fastcgi-server` is the package required, let me put up a puppet change for it... [15:10:29] Coren: can you create the uwsgi queues? [15:10:32] I'll prepare the patches.. [15:13:24] leloiandudu: I've added a patch to add that package, should be installed in all systems in somewhere between 20m-1h [15:13:59] YuviPanda: thanks a lot! [15:28:42] leloiandudu: yw [15:34:36] YuviPanda: Sure. Hang tight. [15:36:38] YuviPanda: Added with no hosts. [15:36:50] \o/ cool [15:48:09] ok, looks like asp.net is working: https://tools.wmflabs.org/rfa-tool/ [15:48:12] thanks, YuviPanda [15:48:18] leloiandudu: w00t [15:48:34] leloiandudu: would be nice if you could document what all you did somewhere [15:49:04] I just followed this guide: http://www.mono-project.com/docs/web/fastcgi/lighttpd/ [15:49:16] i could upload config file somewhere though [15:49:51] leloiandudu: ah, cool! :) [15:57:56] 3Tool-Labs: Document how to install Python modules in a tool's home directory/virtual environment - https://phabricator.wikimedia.org/T63824#939945 (10coren) I don't know enough about python to be certain how reusable that bit is, but there are instructions on setting up //pywikibot// in a virtualenv at https://... [16:00:39] 3Wikimedia-Labs-General: Create ping.wmflabs.org - https://phabricator.wikimedia.org/T56427#939956 (10MarkAHershberger) [16:27:56] valhallasw`cloud: gerrit-patch-uploader now [16:33:21] Coren: hmm, stopping uwsgi seems to put it in a ‘dr’ state [16:33:29] is that when it’s trying to kill it but failing? [16:35:07] YuviPanda: Yes. You may want to use /usr/local/bin/jobkill as the process ender if uwsgi is trying to be too smart for its own good. Look at the terminate_method of the continuous queue [16:35:39] jobkill starts off polite then increasingly more stern if the process misbehaves, and understands process groups [16:35:56] Coren: also, is there any way to tell bigbrother to stop? I can’t migrate gerrit-patch-uploader properly because the lighty job keeps starting up every time. [16:36:20] YuviPanda: Just remove the entry from the .bigbrotherrc [16:36:38] hmm, ok [16:36:57] Coren: I just renamed bigbrotherrc [16:37:02] Coren: and it still keeps getting restarted [16:37:40] should replace it with monit or something some day, so we can do something along the lines of ‘if this http endpoint isn’t responding this way, then restart this' [16:37:41] Hmmm. I don't think I've put in handler for the file just going away. That's a bug, I guess. [16:38:23] Coren: oh, so I’ve to now rename it back and then remove the line? [16:38:27] * YuviPanda does [16:39:09] Yeah, I think it just won't update the tool's config if there is no file at all; which is a conceptual bug. [16:45:42] valhallasw`cloud: yay! https://tools.wmflabs.org/gerrit-patch-uploader/ [16:46:04] Coren: yeah, uwsgi doesn’t seem to be killed properly by GridEngine’s default kill mechanisms [16:58:18] 3Labs-Team, operations: facter: VM detection incorrect in labs - https://phabricator.wikimedia.org/T78813#940085 (10Gage) No use case right now, it's just a defect I noticed when I ran 'facter' with no args to see what values it's reporting. [16:59:24] Coren: hmm, removing the webservice line from .bigbrotherrc still spams me with ‘can not start ‘'' [17:01:57] YuviPanda: is there anything else in there? [17:02:07] probably kill the entire .bigbrotherrc if there's not? [17:02:09] valhallasw`cloud: it’s an empty file. [17:02:15] valhallasw`cloud: that’s what I first did :D [17:02:16] didn’t work [17:02:24] 3Labs-Team, operations: labs VMs install with outdated packages - https://phabricator.wikimedia.org/T85024#940105 (10Gage) Yes I meant when a VM instance is created and booted for the first time. I haven't looked at the installation procedure. If it's from a "golden master" image then this one will be hard to so... [17:02:26] wat. [17:03:35] YuviPanda: trying an empty line now... [17:03:39] valhallasw`cloud: yeah, Coren said might be a bigbrother bug... [17:04:41] [bigbrother] error: /data/project/gerrit-patch-uploader/.bigbrotherrc:1: command not supported [17:04:42] >_< [17:05:04] YuviPanda: how do I start the uwsgi webservice? :P [17:05:29] valhallasw`cloud: webservice2 —release=trusty uwsgi start [17:05:48] then that's what's in .bigbrotherrc now =p [17:06:05] let’s see if that works :) [17:06:35] nope. [17:06:52] ln -s /dev/null [17:07:20] :< [17:07:22] (03PS1) 10Yuvipanda: Add support for uwsgi webservices [labs/toollabs] - 10https://gerrit.wikimedia.org/r/181418 [17:07:47] valhallasw`cloud: bigbrother is staying true to its name :D [17:07:48] YuviPanda: tried rm .bigbroherrc agaisn [17:07:59] * Coren chuckles. [17:08:15] bigbrother will give up after a while anyway iirc [17:08:18] Im back from lunch. Lemme see if I can see the bug. [17:08:48] YuviPanda: Worst case scenario, restarting bigbrother will have it "forget" all the things that aren't there. [17:40:13] Coren hmm, can I send the process any signal with qdel? [17:40:43] -HUP will do a graceful reload [17:43:43] YuviPanda: ya [17:43:46] If the flag [17:43:47] -signo is present, then the specified signal is sent instead [17:43:47] of the SIGKILL signal to any running request whose request- [17:43:47] id is listed on the command line. [17:43:48] A restart is probably not what you want - you'd have no way to _stop_ the process [17:44:14] Coren: oh yeah, totally. I was just thinking of offering a ‘reload’ option too [17:44:40] ugh, wait, that's a different qdel >_< [17:44:52] Coren: do we send it sigterm now? [17:45:08] YuviPanda: you can ssh to the host and SIGwhatever it there, I suppose [17:45:16] YuviPanda: term, then kill after 10 secs [17:45:21] jobkill, which is the default for most queues, sends hup, term then kill [17:45:40] of course, uwsgi ships with a –die-on-term [17:45:42] option [17:45:50] and by default reloads everything on a term [17:45:52] well done [17:45:53] uwsgi [17:46:06] term is the default, btw. [17:46:11] YuviPanda: ah, the famous --you-know-what-you-want-me-to-do option [17:46:14] And that behaviour from uqsgi is insane. [17:46:17] yeah [17:46:28] It should be call --behave-normally [17:49:42] http://uwsgi-docs.readthedocs.org/en/latest/Management.html [17:50:18] ok, now the fucking processes are impossible to kill? [17:50:51] Nothing can survive a sigkill normally. If they resist a sigterm, it's because they catch it explicitly. [17:51:40] no, in this case because I was an idiot and typoing. [17:51:48] well, not exactly typoing [17:51:58] got lost in the multiline command, and kept killing the grep pid... [17:52:35] yeah, specifying —die-on-term works [17:53:15] I still have to figure out why wikibugs ignores sigterm :/ [17:53:32] valhallasw`cloud: have you tried passing —die-on-term? :) [17:53:53] I think asyncio is acting bizarrely or something [17:54:17] yeah, probably [18:00:24] I mean, python gives up on sighup typically [18:03:46] valhallasw`cloud: btw, remember saying how restarting webservers was slow? [18:03:56] YuviPanda: ya [18:03:58] valhallasw`cloud: uwsgi has a bunch of optiosn for that :) live reloading of sorts, a ‘touch’ file [18:04:02] that if you touch it reloads... [18:04:11] oooooh. [18:06:35] mjeh, don't get it. If I send a kill manually it's fine [18:07:09] any other reason why a job might stay in d state for a while...? [18:07:50] valhallasw`cloud: qdel it and see if it is gone on the machine itself? [18:13:29] Unix signal semantics are really well defined, but programmers tend to not bother learning them and making all sorts of odd behavior instead of following what they should. [18:13:35] yeah [18:13:39] ‘term actually is a reload, guys!' [18:14:33] It's not like it's hard. Only sighup has two genuinely different meanings. [18:15:07] term means "please die now". intr means "the user has explicitly asked you to please die now". [18:16:01] hup formally means "the user has gone, please clean up after yourself" but has come to mean "please reload your state" for noninteractive daemons too. [18:16:25] yeah [18:16:35] Want to bet that if it was possible to catch sigkill, there'd be programmers who'd try to prevent it from working? [18:17:03] Coren: no bet :D I am pretty sure ‘yeah, it must have been an accident, let them press yes as well' [18:17:50] Coren: uh, so I guess qdel doesn’t let me send a custom signal, can I somehow figure out what the pid of a particular job is? [18:23:04] No, you can send whatever signal you wan; just replace the value of terminate_method with a signal name [18:23:29] But I really recommend jobkill as terminate_method since that'll work no matter how badly the program misbehaves. [18:23:42] Anything short of SIGKILL may end up with zombie jobs. [18:24:43] Coren: no, I meant just by itself. [18:24:48] Coren: qdel works fine for stopping jobs now [18:24:56] Coren: but I want to also be able to send HUP to it so it can do a reload [18:24:59] as a webservice2 reload [18:26:28] Ah, yes, I see what you mean. There's no clean and straightforward method for that no. I've been meaning to script something for it (check in qstat db for job script and host, ssh to host and find pid, send signal) but there's always something else to take care of before. [18:27:55] yeah [18:27:55] sigh [18:51:06] Now, I _could_ probably write it in perl in about 30 minutes. :-P [18:51:33] noooooo [19:01:38] !perl [19:01:39] what's that? [19:01:44] Oh.. [19:10:40] legoktm: know of any other python webservice tool we can turn into uwsgi? [19:10:56] YuviPanda: sigma's? [19:11:04] legoktm: oh, where’s he? [19:11:15] probably asleep : [19:11:18] :P* [19:11:22] Coren: hmm, do I need to add anything to bigbrother to let it support uwsgi? [19:11:33] YuviPanda: https://tools.wmflabs.org/legobot/cgi-bin/contentcontributor.py/ !!!! [19:11:43] legoktm: cgi-bin, eh? :) [19:11:51] I think it's flask [19:12:00] YuviPanda: You shouldn't; so long as you use the new syntax arguments should be passed to webservice2 untouched. [19:12:10] Coren: yeah, cool! [19:12:14] legoktm: yeah, should be trivial... [19:12:23] legoktm: don’t put it in legobot :| whyyyy [19:12:27] create a new tool for it [19:12:50] but then I don't get pinged when people link to it [19:13:00] YuviPanda: ... yeah, otherwise you might need more than one port assigned dynamically. :-) [19:13:40] Coren: we currently support that only if they’re different types, and that’s still the case :) [19:14:05] legoktm: hehehe [19:14:09] legoktm: fix your IRC client :P [19:25:01] Graaahg! Why does it only work in my VM! [19:31:26] just name it legobot-contentcontributor or something :P [19:33:12] (03PS1) 10Legoktm: Use print_function [labs/tools/extdist] - 10https://gerrit.wikimedia.org/r/181432 [19:33:14] (03PS1) 10Legoktm: Use RotatingFileHandler for logging, set to ~100MB [labs/tools/extdist] - 10https://gerrit.wikimedia.org/r/181433 [19:33:43] legoktm: ^ well done ;) [19:33:44] (03CR) 10Legoktm: [C: 032] Use print_function [labs/tools/extdist] - 10https://gerrit.wikimedia.org/r/181432 (owner: 10Legoktm) [19:33:48] (03Merged) 10jenkins-bot: Use print_function [labs/tools/extdist] - 10https://gerrit.wikimedia.org/r/181432 (owner: 10Legoktm) [19:35:05] :D [20:06:12] !log integration Saved settings in https://integration.wikimedia.org/ci/configure to get jenkins ui language back to english from korean [20:06:17] Logged the message, Master [20:51:41] is auth on beta labs messed up somehow? I'm seeing intermittent failures in the tests since yesterday. [20:52:31] 3Tool-Labs: Toolserver redirect configuration broken after domain move - https://phabricator.wikimedia.org/T85166#940460 (10yuvipanda) [20:57:22] 3Tool-Labs: Toolserver redirect configuration broken after domain move - https://phabricator.wikimedia.org/T85166#940469 (10coren) It's indeed a little worrying that both of the missing redirect do come from MMPs. I've added the redirect from /~erfgoed/ Where was /~locator/ supposed to redirect to? [21:03:26] 3Tool-Labs: Toolserver redirect configuration broken after domain move - https://phabricator.wikimedia.org/T85166#940496 (10Akoopal) Rather simpel, to tools.wmflabs.org/locator/ [21:04:00] 3Tool-Labs: Toolserver redirect configuration broken after domain move - https://phabricator.wikimedia.org/T85166#940498 (10valhallasw) Coren: https://toolserver.org/~nlwikibots is also broken (was also an MMP), but that's not really a huge issue. It was a redirect to https://tools.wmflabs.org/nlwikibots (which... [21:06:08] Coren: Do you have a list of the MMP's? [21:06:17] Makes it easier to reconstruct the missing links.... [21:06:39] multichill: I do not. [21:06:51] buh [21:07:40] Can you redirect ~pywikibot / ~pywikipedia / ~pywikipediabot to http://tools.wmflabs.org/pywikibot/ ? [21:08:00] Not sure what name we used add toolserver coren so let's just do the three of them [21:09:57] Coren: which machine hosts the redirects? [21:10:13] relic [21:10:24] good name coren :P [21:10:36] Hehe [21:10:37] Ok [21:10:44] 3Tool-Labs: Toolserver redirect configuration broken after domain move - https://phabricator.wikimedia.org/T85166#940504 (10coren) Both of those added. [21:23:29] https://phabricator.wikimedia.org/tag/tool_labs/ is archived, multichill ? [21:24:07] Krenair: I'm a dumb users. I just click whatever the damn tool shows me [21:24:17] :) [21:24:18] If I'm not supposed to use it, don't show it to me [21:24:24] Or redirect it? [21:27:53] it says Quim archived it. [21:28:03] > Qgil closed this project.Via Web · Nov 5 2014, 3:05 AM [21:28:05] nono, there's a tool_labs /and/ a tool-labs [21:28:26] tool_labs is archived, tool-labs is not [21:28:35] so tool_labs also doesn't show up in the typeahead [21:29:39] ah, I see what happens. If you type in 'toollabs', you get 'tool_labs' as suggestion, not 'tool-labs' [21:30:08] 3Tool-Labs: Setup (and document) an easy way to run nodejs based tools - https://phabricator.wikimedia.org/T1102#940565 (10Krenair) [21:30:51] 3Tool-Labs: Make http (404, 302, 301 etc) statistics for toolserver.org - https://phabricator.wikimedia.org/T85167#940566 (10Krenair) [21:31:13] 3Tool-Labs: Document and make it easy for people to request new packages in toollabs - https://phabricator.wikimedia.org/T1101#940568 (10Krenair) [21:31:19] Krenair: get yourself in the triagers group and use the batch editor :-p [21:31:26] 3Tool-Labs: Put toolserver.org redirect configuration in git - https://phabricator.wikimedia.org/T85165#940569 (10Krenair) [21:31:32] meh there was only 4 tasks [21:56:11] 3Tool-Labs: Make http (404, 302, 301 etc) statistics for toolserver.org - https://phabricator.wikimedia.org/T85167#940603 (10coren) I'll be collecting sanitized logs for a bit. In the meantime, there are two very big outliers: /~cmarqu/hill/ and /tiles/hikebike/ represent over 95% of the legitimate 404s that I... [22:36:34] 3Quarry: Make "Home" navlink go to profile for logged-in users. - https://phabricator.wikimedia.org/T85175#940705 (10Capt_Swing) 3NEW a:3yuvipanda [23:12:08] (03PS1) 10Legoktm: Escape newlines in IRC output [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/181523 [23:14:50] (03PS2) 10Legoktm: Escape newlines in IRC output [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/181523 [23:17:29] (03CR) 10Merlijn van Deen: [C: 032] Escape newlines in IRC output [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/181523 (owner: 10Legoktm) [23:17:42] (03Merged) 10jenkins-bot: Escape newlines in IRC output [labs/tools/wikibugs2] - 10https://gerrit.wikimedia.org/r/181523 (owner: 10Legoktm) [23:18:51] !log tools.wikibugs legoktm: Deployed 101deca5ee3884d19a61fe7098f8296ddb0c43e0 Escape newlines in IRC output wb2-irc [23:18:53] Logged the message, Master