[00:34:26] jem-: It looks like the tool hasn't been touched since September 4th. [11:15:39] 3Tool Labs tools / 3[other]: Migrate http://toolserver.org/~Emijrp to Tool Labs - 10https://bugzilla.wikimedia.org/60887#c1 (10emijrp) a:3emijrp I'm working on this. Migrated so far: * http://tools.wmflabs.org/wlm-stats/ * http://tools.wmflabs.org/wmcharts/ * http://tools.wmflabs.org/wmcounter/ [13:10:53] Is Darkwind around? I just saw his email [13:21:09] Hmm, I can't find my database. I'm sure I migrated it to eqiad a while back... [13:32:37] liangent: heya [13:32:43] liangent: heya [13:33:39] and is Coren around? [13:33:52] 3Wikimedia Labs / 3Infrastructure: Create -latest alias for dumps - 10https://bugzilla.wikimedia.org/45646#c6 (10Betacommand) Im adding platonides to the CC list and asking for their input, they run the /dumps project on the toolserver [13:34:48] liangent0: don't think so. sunday, etc :) [13:34:54] liangent good luck trying to get ahold of him, you might have better luck turning water to wine [13:35:33] awww, good ol' Betacommand negativism. where would we be without it? :) [13:35:37] YuviPanda: what if a user tells me my tool fails with debug=false? [13:35:55] YuviPanda: Im not a negitivst, Im a realist [13:36:08] liangent0: I think ideal solution would be to see if there's any incoming http body at all at the proxy, and if so let it pass through. if not, generate new. [13:37:10] YuviPanda: when you have dealt with as much stuff as I have you learn to not sugar coat things [13:37:29] ok :) [13:38:25] YuviPanda: yeah though I'm afraid lighttpd generates an ugly error page, especially for 404s [13:38:39] liangent0: you should be able to turn that off in your lighty conf no? [13:39:07] no this affects everybody [13:39:43] YuviPanda: or have it disabled by default [13:39:57] liangent0: in the default lighty conf? yeah, that seems better [13:40:29] so, 1. disable default lighty error pages, 2. if there's non-empty body content from upstream, just let it through [13:40:43] YuviPanda: right [13:40:59] liangent0: alright, let me summarize it on the bug page [13:42:19] bbl [13:43:09] liangent0: commented [13:43:22] 3Wikimedia Labs / 3tools: Let error responses pass through the proxy if they contain contents - 10https://bugzilla.wikimedia.org/64393#c3 (10Yuvi Panda) Talked about this with Liangent on IRC some more. Currently the nginx proxy intercepts 404s, 403s, 500s, 502s and 503s and displays helpful content instead.... [14:32:01] YuviPanda: WAAAAIT [14:32:06] crap. [14:32:07] ouch [14:32:12] what happened [14:32:18] it was deployed anyway. [14:32:18] I just moved it to gerrit :-p [14:32:21] lol [14:32:32] valhallasw: I can resubmit. what's it on gerrit? [14:32:40] YuviPanda: just run git review and you should be fine [14:32:43] there's a .gitreview [14:32:51] valhallasw: ok [14:33:30] (03PS1) 10Yuvipanda: Introduce default and firehose channels [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/133976 [14:33:47] valhallasw: should I self +2? [14:33:49] valhallasw: or can you? [14:33:53] valhallasw: this is currently running anyway :) [14:34:08] (03CR) 10Merlijn van Deen: [C: 032] Introduce default and firehose channels [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/133976 (owner: 10Yuvipanda) [14:34:13] valhallasw: cool! [14:34:21] valhallasw: does it have jenkins-bot setup? [14:34:36] Oh, no, probably not. [14:34:45] (03CR) 10Merlijn van Deen: [V: 032] Introduce default and firehose channels [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/133976 (owner: 10Yuvipanda) [14:34:58] ...and I can't even click 'merge'? grrr. [14:35:40] ok, merged now [14:36:04] jenkins-bot? [14:37:19] valhallasw: I emailed wikitech-l [14:37:23] now to await the flames [14:37:28] scfc_de: runs tests and stuff on gerrit [14:37:59] and more importantly V+2 + auto-submits stuff [14:38:02] yeah [14:38:22] Ah, so no jenkins-bot for a repo = different buttons to press? [14:38:30] lesser buttons :D [14:38:50] scfc_de: yeah, not juts CR+2 , but CR+2, V+2 [14:39:42] valhallasw: should update the config cormat to use YAML at some point as well, but if we're going to replace it with phab at some point maybe I shouldn't bother [14:40:29] yeah [14:40:39] also I'm not a fan of yaml, because it's just another DSL [14:40:55] I'd at least want to replace the X-Bugzilla-Product craziness [14:41:22] I guess you can make an object that returns self['X-Bugzilla-Product'] for self.product or something [14:41:32] otoh, it doesn't really matter [14:41:38] it's a config file that rarely changes [14:41:48] yeah [14:41:50] agreed [14:41:55] overoptimization :P [14:43:15] hello [14:49:49] !ping [14:49:49] !pong [14:49:50] ok [14:49:58] valhallasw: I wonder how we'll port the bots to phabv [14:50:00] I guess as plugins [14:50:04] rather than our current architectures [14:50:31] valhallasw: https://secure.phabricator.com/book/phabdev/article/chatbot/ [14:50:53] valhallasw: hmm, it also does logs! [14:50:54] nice [14:54:49] valhallasw: aren't we supposed to filter gerrit-notification-bot from wikibugs? [14:54:58] ediaWiki / JavaScript: Update jquery.tipsy with $.fn.tipsy.autoBounds - https://bugzilla.wikimedia.org/44382#c1 (Gerrit Notification Bot) Change 133975 had a related patch set uploaded by TheDJ: Tipsy: Added viewable region bounds checking to tipsy https://gerrit.wikimedia.org/r/133975 [14:55:25] aha [14:55:26] my bug [14:55:30] let me fix [14:56:38] (03PS1) 10Yuvipanda: Ignore Gerrit Admin everywhere [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/133977 [14:56:40] valhallasw: ^ [14:57:46] I am testing [14:57:47] it now [15:41:13] YuviPanda: errrrr, I think so, yes [15:41:40] valhallasw: saw my patch? [15:44:12] (03PS2) 10Yuvipanda: Ignore Gerrit Admin everywhere [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/133977 [15:44:57] YuviPanda: What is happening with chicken? Is it unfixable? [15:45:34] valhallasw: good question [15:46:22] err [15:46:24] prtksxna: good question [15:46:26] prtksxna: I do not know [15:46:40] YuviPanda: Can I fix it? [15:46:52] I don't know. give me a bit, let me fix wikibugs first, and then get back [15:46:58] prtksxna: you can try. it uses labs-vagrant [15:47:10] prtksxna: https://wikitech.wikimedia.org/wiki/Labs-vagrant [15:49:29] valhallasw: seems to work. wanna +2 the patch? [16:19:14] YuviPanda: How can I see the LocalSettings.php of some other instance? Do I have permissions on any other? [16:48:57] Anybody know about a large copy of the .es wiki dump files to a individual tool project on tools login? [16:50:24] * Damianz looks at Emilio and wonders if he requires stabbing [16:51:01] Also whoever (I totally don't know your irc nicks) made mw-vagrant a load better, you are awesome and get 1 internet cookie [16:51:33] any known performance issues? [16:52:16] I'm seeing unusual delay between executing a cmd and getting response on some of my bot scripts to where it's nagging me via email about timeouts [16:54:36] Ok, it's the currentevents acct [16:55:52] yeah [16:56:01] just sent an email in reply to his email on the list saying NOOOPE [16:56:16] cp/public/dumps/public/eswiki/20140509/eswiki-20140509-pages-meta-history1.xml.bz2/public/dumps/public/eswiki/20140509/eswiki-20140509-pages-meta-history2.xml.bz2/public/dumps/public/eswiki/20140509/eswiki-20140509-pages-meta-history3.xml.bz2/public/dumps/public/eswiki/20140509/eswiki-20140509-pages-meta-history4.xml.bz2 makes that vm sad [16:56:53] Though wtf is he copying that file =\ [16:57:11] * Damianz goes back to trying to figure out why pip doesn't behave properly behind proxies [16:58:17] http://lists.wikimedia.org/pipermail/labs-l/2014-May/002520.html [16:59:38] * Damianz hates himself for asking redundant questions which he knows the answer to in order to come across as less of a yelling ass.. oh well [17:09:14] !ping [17:09:14] !pong [17:09:54] hasteur: What bots start from tools-login? [17:10:38] a930913: My bots fire off from crontab on tools-login and then get farmed off to qsub execution nodes. [17:11:08] hasteur: tools-login doesn't have crontab, no? [17:12:33] a930913: tools-login has crontab. I was getting warning messages from my script that they were timing out on initial switching from root execution to qsubbed processes. That's why I noticed it. If the server is already under stress it doesn't make sense for me to dump more coals on the fire. [17:14:26] Crontab is on tools-submit or something, no? [17:15:22] All I know is after getting the messages and SSHing in to confirm the error, I observed how over-taxed the box was with copying several eswiki database dumps on the login box [18:12:54] YuviPanda: it helps if you add me as reviewer :-p [18:13:04] Damianz: probably HTTPS_PROXY vs HTTP_PROXY [18:13:27] (03CR) 10Merlijn van Deen: [C: 032] Ignore Gerrit Admin everywhere [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/133977 (owner: 10Yuvipanda) [18:13:34] (03CR) 10Merlijn van Deen: [V: 032] Ignore Gerrit Admin everywhere [labs/tools/pywikibugs] - 10https://gerrit.wikimedia.org/r/133977 (owner: 10Yuvipanda) [18:21:00] valhallasw: hehe, forgot about that [18:27:48] YuviPanda: but is irc3.plugins.ctcp' in the includes in pywikibugs.py? [18:28:20] valhallasw: yeah, I see it [18:28:23] I just reverted back to master [18:28:28] still running same code as before, ofc [19:03:26] hello [19:03:46] is there an email address to reach all admins at once? [19:17:05] valhallasw: Not that simple sadly - stange issue where I see requests going via the proxy (http/https) fine then suddenly it just decides to try a direct connect.... but urllib has the proxy set still. Bizzare [19:21:16] Damianz: that's really weird. I know some libraries for some reason have their own config, but afaik pip just used HTTP_PROXY/HTTPS_PROXY (but needs both set, iirc) [19:21:30] but apparently... [19:21:30] --proxy=PROXY [19:21:30] Have pip use a proxy server to access sites. This can be specified using "user:password@proxy.server:port" notation. If the password is left out, pip [19:21:33] will ask for it. [19:21:46] maybe I'm mistaking pip for easy_install [19:22:25] --proxy should work also, but I get the same behaviour. Gonna try downgrading pip and see if I still hit this, had it working before on the same/pc env, but fails now for some reason =\ [19:38:00] nosy: tools.admin@tools.wmflabs.org should work (NB: "admin", not "admins"). [19:38:19] scfc_de: thx :) [19:38:32] (Or even root@tools.wmflabs.org, I believe.) [19:42:25] root@ goes to general ops list IIRC [19:46:08] On Tools not, I think. Cf. modules/toollabs/templates/exim4.conf.erb, postmaster_mail. [19:49:47] AzaToth: how do I specify a version for package in deps? [19:50:01] I can't seem to find a documentation for that [20:00:01] petan: https://www.debian.org/doc/debian-policy/ch-relationships.html [20:00:53] I did that and debuild seems to ignore that, I even get this: xE: huggle source: depends-on-build-essential-package-without-using-version g++ [build-depends: g++] [20:01:02] I /do/ use a version there [20:01:06] it just ignores it [20:04:51] Sorry, that's all I know :-). Ask in a Debian forum? [20:06:11] petan: Pkg (>= X.Y) [20:06:35] I wish that worked :/ [20:07:01] type "lintian-info -t depends-on-build-essential-package-without-using-version" if you want to get more info for a tag [20:07:38] what is the current Build-Depends now? [20:08:18] it's purposefuly screwed because that was only way it worked debhelper (>= 9), g++ (>= 4.7.0), g++-4.7 | g++4.8, gcc-4.7 | gcc-4.8, libqt4-dbus, libqt4-dev, libqt4-network, libqt4-opengl, libqt4-webkit, libqtwebkit-dev, libqtgui4, libqtcore4, libqt4-xml, qt4-dev-tools, qt4-qmake, python3-dev [20:08:30] lol [20:08:40] remove g++ et al [20:08:40] if I remove g++-4.7 etc, it will just try to build using gcc 6 [20:08:51] * 4.6 [20:09:07] I tried, original was like debhelper (>= 9), g++ (>= 4.7.0), libqt4-dbus, libqt4-dev, libqt4-network, libqt4-opengl, libqt4-webkit, libqtwebkit-dev, libqtgui4, libqtcore4, libqt4-xml, qt4-dev-tools, qt4-qmake, python3-dev [20:09:24] however that was using gcc 4.6 or older which MUST not happen [20:09:42] build depends doesn't affect the build env [20:09:52] it just states which needs to exist [20:09:55] why is it called build depends then [20:10:13] it's packages that the build depends upon [20:10:17] ok, but it didn't even install gcc 4.7 or newer [20:10:39] ok so when I type g++ (>= 4.7.0) in build depends it will just install g++ 4.6 or older? [20:10:44] that makes no sense [20:10:59] you mean install in a pbuilder? [20:11:46] when I want to build that package into .deb file, it should at least tell me that I don't have packages required to build other than starting the build which later fail because I don't have them [20:11:52] if your package must use g++ 4.7 or above to build, then it's currect to have a versioned build dep [20:12:14] yes it MUST be 4.7 or newer otherwise it doesn't build [20:12:17] ok [20:12:19] it's c++11 [20:13:55] right now thanks to that I have g++-4.8 in deps explicitly, it works, but if I just leave g++ (>= 4.7.0) there, it compiles with older gcc and fails [20:14:13] it's nasty workaround but so far only solution [20:14:23] g++ have epoch [20:14:32] so type g++ (4:4.7) [20:14:38] g++ (>= 4:4.7) [20:14:52] ok [20:15:12] http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version [20:15:23] "This is a single (generally small) unsigned integer. It may be omitted, in which case zero is assumed" [20:15:34] so 4.7.0 implies 0:4.7.0 [20:15:41] and 4.4 > 0:4.7 [20:15:48] aha [20:16:01] that is probably cause for this [20:16:22] epoch is a way to fix people fucking things up regarding versions [20:31:33] AzaToth: now it fails properly but meh... launchpad can't handle that [20:32:05] it tells me the box doesn't meet the build requirements while it easily can do just apt-get install g++-4.7 to fix that [20:36:44] haven't used launchpad [20:37:33] I usually use cowbuilder locally to test building the package [20:51:54] 3Wikimedia Labs / 3tools: Copy contents of https://svn.toolserver.org/ to Wikimedia git - 10https://bugzilla.wikimedia.org/58801#c13 (10nosy) Ok the stuff is still sitting in my home - where should I put it next? [21:08:25] nosy: could you please delete my toolserver repo and its labs copy? [22:42:54] 3Wikimedia Labs / 3tools: Tool Labs: Provide anonymized view of the user_properties table - 10https://bugzilla.wikimedia.org/58196 (10Tisza Gergő)