[00:40:18] <Aaron|home>	 TimStarling: should I assume you are busy with lua?
[00:41:55] <TimStarling>	 you want your job queue stuff reviewed?
[00:43:12] <Aaron|home>	 well that depends on being busy with lua
[00:45:25] <TimStarling>	 "* A 'disable' option has been added to wfShellExec() to disable ulimit, since it seems to break any attempt to call a PHP script."
[00:45:29] <TimStarling>	 that's curious
[00:46:00] <TimStarling>	 in what way does it break exactly?
[00:46:52] <Aaron|home>	 oh, and you could probably look at https://gerrit.wikimedia.org/r/#/c/47378/ last
[00:47:15] <Aaron|home>	 using the redis aggregator indirectly makes that less important
[00:48:24] <Aaron|home>	 TimStarling: but the problem is that it won't start at all (I think I got "libgcc_s.so.1 must be installed for pthread_cancel" before on a local box)
[00:48:53] <Aaron|home>	 I never fully found out why it breaks shelling out to php scripts so much
[00:48:55] <TimStarling>	 even with a very large virtual memory limit?
[00:49:14] <TimStarling>	 PHP probably uses a lot of virtual memory to start up
[00:49:26] <TimStarling>	 try setting it to 2GB
[00:49:44] <Aaron|home>	 I'll try when I'm on a ubuntu again
[00:51:10] <Aaron|home>	 did you ever get that pthread_cancel error before?
[00:51:28] <Aaron|home>	 try shelling out from php to php (in cli and in apache)
[00:51:43] <Aaron|home>	 I'm pretty sure it tends to break in apache
[00:51:48] <TimStarling>	 I haven't seen that particular message
[00:51:59] <TimStarling>	 but it sounds like dynamic linking failed
[00:52:06] <Aaron|home>	 I remember wasting a lot of time on that and gave up on it
[00:52:54] <Aaron|home>	 it breaks on the site too, not just my laptop
[00:53:20] <Aaron|home>	 not 100% if its the same error, though quite possibly it is
[00:54:05] <TimStarling>	 ah yes, I get that error with an appropriate max memory
[00:54:54] <TimStarling>	 at 100MB, I get:
[00:54:57] <TimStarling>	 php: error while loading shared libraries: libkrb5.so.26: failed to map segment from shared object: Cannot allocate memory
[00:55:30] <Aaron|home>	 I thought I tried bumping the limit
[00:55:31] <TimStarling>	 at 200MB or 300MB I get that pthread_cancel error
[00:55:37] <TimStarling>	 at 400MB it works
[00:55:42] <Aaron|home>	 though I didn't go up to GBs
[00:55:44] <Aaron|home>	 heh
[00:56:37] <TimStarling>	 unstripped libraries probably affect it
[00:56:58] <TimStarling>	 using cgroups instead of ulimit works, of course
[01:36:55] <TimStarling>	 AaronSchulz: maybe just disable the virtual memory limit with 'memory' => false, instead of disabling all limits
[08:23:56] <Nemo_bis>	 Ah, I didn't even know. www.amazon.com/Wikimedia-Foundation-Wikipedia/dp/B0088P2A7A/
[08:53:38] <hashar>	 zeljkof: hey :-]
[08:54:07] <zeljkof>	 hashar: bonjour :)
[08:54:12] <apergos>	 ah a DanielK_WMDE
[08:55:19] <apergos>	 I'm still getting a lot of cronspam from wikidata lab instances; can I pass the info on to you to go to the right people?
[08:57:01] <ori-l>	 cronspam:
[08:57:21] <apergos>	 yes, all output from cron jobs in labs instances gets sent to ops
[08:57:24] <ori-l>	 "Dear Sir / Madam, I am a unix task scheduling daemon. Years ago my father bequeathed to me a fortune of untold riches."
[08:57:27] <apergos>	 to everyone in ops
[08:57:33] <apergos>	 we are getting some once a minute
[08:57:48] <Susan>	 I lol'd at Ori.
[08:57:55] <apergos>	 at least that would be more entertaining
[08:57:59] <apergos>	 instead I get for example:
[08:58:00] <ori-l>	 I know, I'm just having fun imagining a cron / Nigerian 409 scam crossover
[08:58:07] <apergos>	  	Cron <root@wikidata-testclient> sudo -u www-data /usr/bin/php /srv/mediawiki/extensions/Wikibase/lib/maintenance/pollForChanges.php --since "yesterday" >> /var/log/wikidata-replication.log
[08:58:16] <apergos>	 No entry for terminal type "unknown";
[08:58:16] <apergos>	 using dumb terminal settings.
[08:58:23] <apergos>	 those are every two minutes
[08:58:33] <ori-l>	 Cron is nothing if not regular
[08:59:01] <apergos>	 same from these   Cron <root@wikidata-dev-9> sudo -u wikidata /usr/bin/php /srv/devclient/w/maintenance/runJobs.php >> /tmp/runJobs.log
[08:59:04] <apergos>	 but once a minunte
[08:59:25] <apergos>	 same from these   	Cron <root@wikidata-dev-8> sudo -u wikidata /usr/bin/php /srv/testclient-en/w/extensions/Wikibase/lib/maintenance/pollForChanges.php --since "yesterday" >> /var/log/en-wikidata-replication.log
[08:59:30] <apergos>	 but once every two minutes
[09:00:39] <apergos>	 best is to make sure that stderr goes to the same file too  on all of these
[09:04:19] <gerrit-wm>	 New patchset: Jeroen De Dauw; "Regsiter dependencies for Ask" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/49214
[09:04:26] <gerrit-wm>	 New patchset: Jeroen De Dauw; "Regsiter dependencies for Ask" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/49214
[09:19:37] <gerrit-wm>	 New review: Hashar; "Patch Set 2: Verified+2 Code-Review+2" [integration/jenkins-job-builder-config] (master); V: 2 C: 2;  - https://gerrit.wikimedia.org/r/49214
[09:19:37] <gerrit-wm>	 Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/49214
[09:22:48] <gerrit-wm>	 New review: Krinkle; "Patch Set 2:" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/49214
[09:24:37] <hashar>	 Krinkle: so is the check style plugin working properly ? :-]
[09:24:44] <Krinkle>	 Yes
[09:24:48] <hashar>	 \O/
[09:24:59] <hashar>	 Krinkle: I wanted to look at fixing the Violation plugin.
[09:25:04] <hashar>	 but my java is really awful hehe
[09:25:09] <Krinkle>	 hashar: although it would be nice if the link in the gerrit jenkins-bot comment wouldn't point to the console
[09:25:37] <hashar>	  console / the check style report ?
[09:26:26] <hashar>	 Krinkle: that is the status_url parameter in Zuul which his global. I am wondering if it can be overridden on a per job basis
[09:27:30] <Krinkle>	 hashar: I'm not sure what you mean by "console / the check style report ?". I said it would be nice if it wouldn't (would not) point to the console
[09:27:38] <Krinkle>	 ... and instead point to where it should point
[09:27:48] <hashar>	 yeah what I said :-]
[09:28:01] <hashar>	 so instead of having …./console  we want something like …./checkstyle_report
[09:28:07] <Krinkle>	 Right
[09:28:11] <Krinkle>	 Or just ../
[09:28:19] <Krinkle>	 because the main page of the job is more nicer to look at
[09:28:30] <Krinkle>	 and contains the same link, bigger and up front
[09:28:36] <Krinkle>	 same for phpunit tests by the way
[09:28:45] <Krinkle>	 console is for us if we need to debug jenkins
[09:28:55] <Krinkle>	 Shouldn't point to that all the time
[09:29:25] <Krinkle>	 and of course, when we migrate away from gazillion jobs to build tasks, there'd be one link, to the job main page and from there links to phpunit, checkstyle etc.
[09:29:36] <Krinkle>	 like there are already, except now it has only one link on each job page
[09:30:01] <Krinkle>	 this is a good example where jenkins shows that it shouldn't be used like we set it up with zuul job-level macros instead of build level
[09:31:24] <Krinkle>	 hashar: btw, What is the " - '{name}-{ext-name}-testextensions-{mwbranch}':" repetition for?
[09:31:27] <Krinkle>	 https://gerrit.wikimedia.org/r/#/c/49214/2/mediawiki-extensions.yaml
[09:31:52] <Krinkle>	 - '{name}-{ext-name}-testextensions-{mwbranch}': name: mwext ext-name: Foo
[09:31:53] <Krinkle>	 - '{name}-{ext-name}-testextensions-{mwbranch}': name: mwext ext-name: Bar
[09:31:56] <Krinkle>	 looks silly
[09:32:04] <Krinkle>	 - 'mwext-Foo-testextensions-{mwbranch}':
[09:32:06] <Krinkle>	 - 'mwext-Bar-testextensions-{mwbranch}':
[09:32:07] <Krinkle>	 ?
[09:35:29] <hashar>	 Krinkle: sorry too many private chats :-]
[09:35:41] * hashar  context switch to here

[09:36:00] <hashar>	 Krinkle: so
[09:36:09] <hashar>	  '{name}-{ext-name}-testextensions-{mwbranch}'  is a name of a template
[09:36:12] <hashar>	 which is defined under a job-template
[09:36:16] <hashar>	 job-template:  part
[09:36:25] <hashar>	 if you want JJB to call that template, the name must match exactly
[09:36:33] <hashar>	 so: - '{name}-{ext-name}-testextensions-{mwbranch}': name: mwext ext-name: Bar
[09:36:36] <hashar>	 it is basically:
[09:36:44] <hashar>	 call the  '{name}-{ext-name}-testextensions-{mwbranch}' template
[09:36:53] <hashar>	 and pass it the parameter  name = mwext   and ext-name =  Bar
[09:36:56] <hashar>	 that is really ugly
[09:37:24] <Krinkle>	 I know
[09:37:33] <Krinkle>	 but I also know it can be optimised to call the same template multiple times
[09:37:35] <hashar>	 that specific part will be removed whenever we start using Composer to resolve extension dependencies
[09:37:51] <Krinkle>	 most of these entries don't have dependencies
[09:37:56] <hashar>	 then the  test extension job will simply call  `composer install` and use the provided composer.json to resolve the dependencies
[09:38:01] <Krinkle>	 So there is more going on, this defines the job, not just the dependencies
[09:39:05] <hashar>	 yeah that is overriding the default jobs generated via:
[09:39:10] <hashar>	 jobs:  - mwext-check-jobs
[09:39:32] <hashar>	 that is the same story for the pep8 jobs
[09:39:47] <hashar>	 most extensions do not have any python script so the pep8 jobs are not included by default (in mwext-check-jobs)
[09:40:17] <hashar>	 hence to create the pep8 job for a given extension I call the template for that ext:   - '{name}-{ext-name}-pep8':  name: mwext ext-name: WikimediaMaintenance
[09:58:58] <Krinkle>	 hashar: but why repeat the template itself
[09:59:06] <Krinkle>	 that makes the template completely useless
[09:59:09] <Krinkle>	 as it isn't a template
[09:59:16] <Krinkle>	 it isn't used more than 1
[09:59:32] <Krinkle>	 everytime you need it you repeat the entire source code of a template, hah, that's no template.
[10:02:11] <hashar>	 Krinkle: I am not sure I understand
[10:02:26] <hashar>	 the template '{name}-{ext-name}-testextensions-{mwbranch}' is called for several extensions
[10:02:32] <hashar>	 so
[10:02:38] <hashar>	 - project:  name: mwext
[10:02:47] <hashar>	 then it has  ext-name:  [some looong list of all extensions]
[10:03:10] <hashar>	 JJB then do a foreach of  ext-name  and call the   -mwext-check-jobs  group which in turns include 7 templates
[10:03:29] <hashar>	 that generates basic jobs that all look the same
[10:03:38] <hashar>	 the other calls are more specific and override the generic jobs.
[10:03:48] <Krinkle>	 I don't know what that means
[10:04:03] <Krinkle>	 What I know is that the "template" '{name}-{ext-name}-testextensions-{mwbranch}' is repeated as many times as there are extensions in that code
[10:06:08] <hashar>	 na only for extensions that have dependencies
[10:06:29] <hashar>	 like ten of them
[10:06:51] <hashar>	 all the other extensions calls the template with default parameters
[10:06:58] <hashar>	 aka dependencies set to ""
[10:07:35] <hashar>	 the dependencies variable is set to "" at the project level:    project:   dependencies: ""
[10:07:44] <hashar>	 the more specific calls simply override that value
[10:10:42] <hashar>	 !g 47664
[10:10:43] <wm-bot>	 https://gerrit.wikimedia.org/r/#q,47664,n,z
[11:40:29] <gerrit-wm>	 New review: Krinkle; "Patch Set 2: Code-Review-2" [integration/jenkins] (master) C: -2;  - https://gerrit.wikimedia.org/r/38645
[12:00:12] <gerrit-wm>	 New patchset: Platonides; "Update find-entries.php to 2013" [mediawiki/tools/code-utils] (master) - https://gerrit.wikimedia.org/r/49230
[13:04:03] <hashar>	 re
[13:59:00] <apergos>	 DanielK_WMDE:   around?
[14:34:24] <DanielK_WMDE>	 apergos: back now, what's up?
[14:36:55] <apergos>	 hey
[14:37:12] <apergos>	 I want to nag you or to pass a nag on via you to folsk on the wikidata labs instances
[14:37:43] <apergos>	 I'm getting cronspam (so is all ops) 1 a minute from two jobs and 1 every two minutes from another
[14:37:57] <apergos>	 this adds up to thousands a day of course; the jobs are:
[14:38:12] <apergos>	 Cron <root@wikidata-testclient> sudo -u www-data /usr/bin/php /srv/mediawiki/extensions/Wikibase/lib/maintenance/pollForChanges.php --since "yesterday" >> /var/log/wikidata-replication.log
[14:38:27] <apergos>	 Cron <root@wikidata-dev-9> sudo -u wikidata /usr/bin/php /srv/devclient/w/maintenance/runJobs.php >> /tmp/runJobs.log
[14:38:40] <apergos>	 Cron <root@wikidata-dev-8> sudo -u wikidata /usr/bin/php /srv/testclient-en/w/extensions/Wikibase/lib/maintenance/pollForChanges.php --since "yesterday" >> /var/log/en-wikidata-replication.log
[14:38:45] <apergos>	 I *think* that's all of the
[14:38:46] <apergos>	 m
[14:38:54] <apergos>	 they produce whines like this:
[14:39:16] <apergos>	 No entry for terminal type "unknown";
[14:39:18] <apergos>	 using dumb terminal settings.
[14:39:33] <apergos>	 it's best if folks would just capture stderr to a file too as they already do with stdout
[14:40:11] <apergos>	 if this could happen for all the wikidata lab cron jobs, that would make me very happy (but might be useful for you folks too, to know when something is broken)
[14:40:17] <apergos>	 DanielK_WMDE: ^^
[14:44:30] <DanielK_WMDE>	 apergos: or maybe termcaps should be fixed on labs?... what do you think?...
[14:44:54] <DanielK_WMDE>	 apergos: anyway, please talk to aude and silke_wmde about this, i don't know anything about the labs setup.
[14:45:28] <apergos>	 are those their nicks here?
[14:45:33] <apergos>	 I see one such nick
[14:46:13] <apergos>	 because cron jobs break in a numbe of ways which are all invisible to the user if they don't capture stderr/out, it's always best for them to do so
[14:47:03] <DanielK_WMDE>	 apergos: silke is in #wikimedia-wikidata
[14:47:12] <apergos>	 ah thanks
[14:47:30] <DanielK_WMDE>	 apergos: usually, i would expect us to get an email with these errors...
[14:47:36] <aude>	 i'd ask silke, but if she wants to delegate that for me to fix, then ok
[14:47:48] * aude  trying not to interfere with puppet stuff there

[14:47:54] <DanielK_WMDE>	 yay puppet :P
[14:48:06] <apergos>	 ok, let me ask and see
[14:48:14] <aude>	 if those are on puppet, then they can be fixed in gerrit by anyone :)
[14:48:27] <aude>	 anyway, we should not be using pollForChanges anymore
[15:08:41] <gerrit-wm>	 New patchset: Hashar; "triggers for operations-apache-config-lint" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/49242
[15:10:15] <gerrit-wm>	 New review: Hashar; "Patch Set 1: Verified+2 Code-Review+2" [integration/zuul-config] (master); V: 2 C: 2;  - https://gerrit.wikimedia.org/r/49242
[15:10:16] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/49242
[15:11:28] <hashar>	 grmblblblbl
[15:24:25] <anomie>	 ^demon- Want to review something Lua-related for me?
[15:26:41] <gerrit-wm>	 New patchset: Hashar; "update 'recheck' regexp" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/49245
[15:27:09] <gerrit-wm>	 New review: Hashar; "Patch Set 1: Verified+2 Code-Review+2" [integration/zuul-config] (master); V: 2 C: 2;  - https://gerrit.wikimedia.org/r/49245
[15:27:09] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/49245
[15:28:29] <hashar>	 ce soft est moisi
[15:34:55] <hashar>	 (?im)^Patch Set \d+:\n\n\s*recheck\.?\s*$
[15:37:11] <^demon>	 anomie: Locale stuff?
[15:37:19] <anomie>	 ^demon- Documentation
[15:37:27] <anomie>	 https://www.mediawiki.org/wiki/User:Anomie/Lua_reference_manual
[15:37:52] <^demon>	 Oh wow.
[15:38:02] <anomie>	 I tried to cut out stuff not relevant to Scribunto, and add in bits that are missing from https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual
[15:39:15] <^demon>	 Looks good, just skimming it.
[15:42:21] <gerrit-wm>	 New patchset: Hashar; "update ALL 'recheck' regexp" [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/49249
[15:42:36] <gerrit-wm>	 New review: Hashar; "Patch Set 1: Verified+2 Code-Review+2" [integration/zuul-config] (master); V: 2 C: 2;  - https://gerrit.wikimedia.org/r/49249
[15:42:37] <gerrit-wm>	 Change merged: Hashar; [integration/zuul-config] (master) - https://gerrit.wikimedia.org/r/49249
[15:43:16] <hashar>	 2013-02-15 15:43:09,219 INFO zuul.Jenkins: Launch job operations-apache-config-lint for change <Change 0x7fa32895c6d0 49243,1> with dependent changes []
[15:43:17] <hashar>	 yeah
[15:59:18] <gerrit-wm>	 New patchset: Hashar; "linter for our Apache configurations" [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/49251
[16:24:31] <gerrit-wm>	 New review: Hashar; "Patch Set 1: Verified+2 Code-Review+2" [integration/jenkins-job-builder-config] (master); V: 2 C: 2;  - https://gerrit.wikimedia.org/r/49251
[16:24:31] <gerrit-wm>	 Change merged: Hashar; [integration/jenkins-job-builder-config] (master) - https://gerrit.wikimedia.org/r/49251
[16:24:56] <^demon>	 Restarting gerrit to pick up config change, don't panic.
[16:30:58] <Nemo_bis>	 hehe
[16:31:25] <Nemo_bis>	 ^demon: is it possible to change the diff style or is this something that would cause huge drama? :)
[16:31:36] <^demon>	 What do you mean?
[16:32:06] <Nemo_bis>	 ^demon: I mean like getting rid of the rev vs. green and use something like the 1.20 diff colours
[16:32:10] <Nemo_bis>	 *red
[16:32:38] <^demon>	 Ugh.
[16:33:33] <Nemo_bis>	 With the rather neutral background (non "vomit-green"), maybe it could be possible to just adopt the MediaWiki colours to avoid bikeshedding...
[16:33:59] <^demon>	 I doubt upstream would like the new diff colors.
[16:34:31] <^demon>	 I brought this up awhile back when I reskinned gerrit upstream...maybe changing diff colors. They like red/green.
[16:34:52] <Nemo_bis>	 It's not configurable? :o
[16:35:36] <^demon>	 I mean, we have our own CSS.
[16:36:00] <^demon>	 But the diff color isn't configurable, no.
[16:36:05] <Nemo_bis>	 Yes, can't it also change the diffs?
[16:36:07] <Nemo_bis>	 Aww
[16:36:30] <^demon>	 We could via our css, I'm saying there's no core theme.whatever options for diffs.
[16:46:24] <MaxSem>	 ffs, not another Vector clone please, or people will start signing with ~~~~
[18:18:32] <vp_>	 hello.please help me with mobile fronted extension
[18:19:19] <vp_>	 thanks for joing me
[18:19:47] <vp_>	 the error is that when i visit my main page through desktop it is mobile version
[18:21:33] <vp_>	 and when i try to redirect to a subdomain with mobileurltemplate settings like m.%h1.%h2 it doesnot connect with index.php
[18:22:38] <vp_>	 hello
[18:22:50] <sumanah>	 hi vp_
[18:23:00] <sumanah>	 vp_: the #wikimedia-mobile channel might help you better
[18:23:07] <vp_>	 thanks mate for reply
[18:23:24] <vp_>	 I want your help me mobile fronted extension
[18:24:28] <vp_>	 he error is that when i visit my main page through desktop it is mobile version [10:23] <vp_> and when i try to redirect to a subdomain with mobileurltemplate settings like m.%h1.%h2 it doesnot connect with index.php
[18:24:51] <vp_>	 sumanah, are you here?
[18:25:55] <sumanah>	 vp_: I am here, but I don't know enough to help you personally. The #wikimedia-mobile channel is often a better place to get help with mobile optimization issues
[18:26:14] <sumanah>	 You could also try the mailing list https://lists.wikimedia.org/mailman/listinfo/mobile-l .
[18:26:26] <vp_>	 Thanks sumanah i will check it
[20:28:49] <mwalker>	 \whois Nemo_bis
[20:28:55] <mwalker>	 well that'll work too
[20:29:03] <mwalker>	 Nemo_bis: question for you if you're there
[21:02:17] <Nemo_bis>	 mwalker: yes?
[21:50:31] <mwalker>	 Nemo_bis: my question for you was -- JavaScript inclusion in XML in theory should be wrapped in a CDATA tag so that the DOM parser doesn't choke -- but in CentralNotice we just inject raw unescaped JS via $(...).prepend(data) and this just seems to work. any idea why?