[13:03:03] hi there. is ther no magic word or any other possibility to recognize the actual (full) URL of the article/page? [13:06:26] {{canonicallurl:{{FULLPAGENAME}}}} [13:13:18] err [13:13:26] that won't solve my problem sadly [13:13:53] I want something like that as an output: http://en.wikipedia.org/w/index.php?title=User_talk:Aharon&action=edit&editintro=Template:AFC_submission/user_talk_editintro&preload=Template:AFC_submission/user_talk_preload/sandbox&preloadtitle=Your+submission+at+%5B%5BWP%3AAFC%7CArticles+for+creation%5D%5D§ion=new&appendtext=blubb [13:14:08] I need the "blubb" as an variable [13:14:12] RoanKattouw: ^ [13:14:51] Oh [13:15:05] I don't believe that's possible without modifying the software or writing an extension [13:15:14] that's really sad [13:16:06] as you can see (if you click on that url), I want that "blubb" in the preload text, but I don't know how to give that parameter that sandbox/preloadtext [13:16:41] canonicallurl is a misspelling BTW [13:16:44] It's canonicalurl [13:17:05] But yeah there's no way to access query string variables in wikitext [13:17:22] Ordinarily that would be a bad idea anyway, with parser caching and all [13:18:31] yeah, I thought using the url and then striping out the needed part. that would sove my problem [13:18:41] oh and that was a copy n pasted text XD [13:19:07] I checked mediawiki for the information, and I saw that this wouldn't solve my needs [13:21:40] any other ideas how I'm able to solve the problem to give the preloadtext a parameter? [13:22:46] I have no idea [13:23:30] RoanKattouw: is maybe appendtext working? we could change the existing template "easily"... [13:23:56] I don't think so [13:24:16] This sounds like something that we should be supporting (appendtext that is) [13:24:23] So I suggest you file a bug [13:24:27] yeah, I already tried this using an url, but it didn't worked... [13:24:46] heh... [13:24:58] yeah, I will fill one... [13:38:06] https://bugzilla.wikimedia.org/show_bug.cgi?id=31919 [14:02:29] Am I just missing Krinkle when he is on? [14:41:01] <^demon> hashar: I talked with Krinkle last night. He said the two of you would be collaborating on the testswarm stuff over the next week or so :) [14:42:21] hello ^demon ! [14:42:39] I have talked with Krinkle thursday evening about his progress on testswarm deployement [14:42:55] basically: he does not have any access to the cluster so progress is 0% :-D [14:43:23] <^demon> We can all make puppet changes ;-) [14:43:31] we will probably have to package testswarm as a debian package then deploy it through puppet [14:43:41] <^demon> Right, that's what I suggested to him last night. [14:44:10] meanwhile, do you have access to the subversion pre commit hook? [14:44:21] I get a nice (exit code 255) with no output [14:44:23] <^demon> Yes, I've got rights on formey. [14:45:16] I try to commit a simple PHP file which pass the PHP linter [14:45:32] it is tests/phpunit/inludes/HtmlTest.php if it can help looking at the logs [14:47:23] That means we finally have a pre-commit hook that blocks invalid php! [14:47:45] <^demon> It should, yes. [14:47:51] <^demon> And it did after I wrote+deployed them. [14:47:59] <^demon> But afaik, I changed nothing and they just Stopped Working. [14:48:18] <^demon> I can't see anything different about them from the version I deployed. [14:48:31] are you referring to the pre commit hooks? [14:48:56] <^demon> Yes. [14:49:07] is there anything specific there beside linting? [14:49:12] ^demon. if it blocks everything, it also blocks invalid php :) [14:49:22] <^demon> hashar: Empty commit summary. [14:49:36] *hashar goes to write more text [14:50:55] it would help to have the hop give a message :D [14:51:48] <^demon> It should. [14:52:26] <^demon> The version in /svnroot/mediawiki/hooks is identical to what's in http://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/subversion/hooks/ for pre-commit and HooksCommon.inc [14:52:39] ahaaa [14:52:40] <^demon> post-commit I never finished, so is running something not in svn yet. [14:52:51] there is a version in puppet git too! [14:53:54] <^demon> Ah yes, I did import those over. [14:54:13] <^demon> They probably should be in puppet anyway. [14:54:15] you might want to delete the SVN one and keep only the git as a reference [14:55:19] <^demon> Right, I think just fixing up the ones in puppet and finishing their puppetization would be best. [15:07:17] still blocked, Idont understand the issue :-( [15:07:42] will fetch a fresh copy of trunk [15:19:47] You guys seem to have broken something now [15:19:53] ialex svn: Commit blocked by pre-commit hook (exit code 255) with no output. [15:25:40] I am looking at https://gerrit.wikimedia.org/r/#q,status:merged,n,z [15:25:52] mark had a lot of changes merged in production [15:27:38] <^demon> I swear, I didn't touch it. [15:27:47] i'll have a look in a bit [15:27:49] <^demon> I'm confused wth is going on with that pre-commit hook. [15:28:23] puppet: /files/svn/hooks/pre-commit is not +x might be an issue [15:28:39] <^demon> hook files aren't managed by the svn class yet. [15:28:43] <^demon> That's still manual. [15:34:48] ^demon, hashar: The pre-commit hook breakage is still being reported by TrevorParscal [15:35:05] <^demon> I haven't touched anything. [15:35:09] I am sure it is broken for everyone [15:35:10] <^demon> Before or after. [15:35:19] And I sure hope this'll be fixed in the next hour and a half or Nikerabbit and I won't be able to do our scheduled deployment (which involves merging stuff into 1.18wmf1) [15:35:21] and it is most probably related to some deployment this afternoon [15:35:36] I do not have an account on formey to verify it :/ [15:35:53] hm [15:36:07] on the good side, mark said he will have a look at it [15:36:08] Well at least you guys are aware of the issue then [15:36:18] I have to step out now to cook dinner [15:37:41] *hashar is out for shopping / bread / cooking [15:37:45] <^demon> pre-commit hasn't been touched since early August. [15:37:47] <^demon> fwiw. [15:38:08] <^demon> And it's +x [15:38:13] good! [15:38:31] i can't commit a change to a js file [15:38:35] <^demon> Yes, we know. [15:38:38] there might something else that is blocking the script [15:38:47] <^demon> I'm wondering if it's sillyshell. [15:38:58] I think I saw a change to sillyshell [15:39:52] i'm getting https://gist.github.com/1309337 [15:42:44] changes mades to manifests/svn.pp [15:42:47] https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=history;f=manifests/svn.pp;h=5bc57c8bc0bfeacfd4e66bd9518d7fffe6657a22;hb=HEAD [15:42:53] gee, i sure wish my code was in a git repo, I could continue committing while our central repo was borked??? [15:43:27] you can probably 'git init' your svn working copy [15:43:44] ugh [15:44:11] i think we should move the wikidom stuff to a github account until WMF has finished moving to git [15:44:40] <^demon> Just because svn broke for an hour or two? :p [15:44:52] it's fixed now? [15:45:03] <^demon> Not yet, but I'm looking into it. [15:45:08] ok [15:45:15] thanks for looking into it [15:45:16] <^demon> So is mark. [16:10:09] ^demon|away: svn seems to be working again [16:10:18] so, thank you - to whoever did whatever [17:00:55] Nikerabbit: So, i18n deploy? [17:03:39] RoanKattouw: sure [17:03:45] Alright, so [17:03:54] Step 1 is merging this stuff into the 1.18wmf1 branch [17:04:32] Are you familiar with how to do that? [17:05:18] haven't done that before [17:06:02] OK [17:06:12] Do you have a checkout of 1.18wmf1? [17:07:21] If not, check it out from svn+ssh://svn.wikimedia.org/svnroot/mediawiki/branches/wmf/1.18wmf1 [17:07:38] doing it right now [17:07:48] Cool [17:08:40] takes a while [17:09:01] Yeah [17:09:27] done [17:09:36] When it's finished, you should merge the individual revs using svn merge -c REVID FROMPATH TOPATH [17:10:12] one at a time? [17:10:28] So e.g. svn merge -c 99630 filesystem/path/to/trunk/phase3 filesystem/path/to/1.18wmf1 and svn merge -c 100332 filesystem/path/to/trunk/extensions filesystem/path/to/1.18wmf1/extensions [17:10:30] Yeah [17:10:35] You can combine multiple revs in one command [17:10:35] aww [17:10:38] Using -c 123 -c 456 [17:10:53] But they must be in the same path (phase3 vs extensions in this case) [17:11:33] Your phase3 revs are -c 99630 -c 99680 -c 100021 -c 100115 [17:11:52] okay [17:11:58] (I have a user JS thingy that generates (parts of) svn merge commands from Special:Code revision listings) [17:12:44] Be warned that it is possible that old revisions may not apply cleanly, in which case SVN will ask you to resolve the conflict. This works pretty much the same as resolving conflicts during svn update [17:12:57] hmm [17:12:58] right [17:13:03] so I would do svn merge -c 99630 -c 99680 -c 100021 -c 100115 trunk/ 1.18wmf1/ ? [17:13:12] trunk/phase3 [17:13:48] okay, let's see what happens [17:14:01] You need to specify the paths such that $FROMPATH/includes/Foo.php and $TOPATH/includes/Foo.php are different incarnations of the same file [17:15:08] that succeeded [17:15:11] Good [17:15:16] same for narayam and then commit? [17:15:22] Yes, BUT [17:15:31] After you run the Narayam merge, you need to do two things [17:15:51] One is that there will be lots of useless property changes visible in svn status, you need to clean those up before committing [17:15:57] I have a nice one-line script for that [17:16:07] $ cat ~/bin/svnsucks [17:16:09] #! /bin/bash [17:16:11] svn st | grep '^ M' | awk '{print $2}' | xargs svn revert [17:16:45] I approve the command name [17:17:00] Two is that, after you've cleaned up the property-changes-for-unchanged-files pollution, you should glance over the output of svn diff and check that it looks somewhat sane [17:17:23] Like, there are no conflict markers in your commit, the changed files pass php -l, that sort of thing [17:17:56] do you have a script for that too? [17:18:22] Unfortunately, no [17:18:34] I just type it when I need it [17:19:17] for f in `svn st | awk '{print $2}'`; do php -l $f; done IIRC [17:22:17] xargs -n1 could also work [17:22:51] Oh, nice [17:22:55] I didn't know that existed [17:23:24] okay, the diff looks sane now [17:23:59] now commit? [17:24:14] Yes [17:24:22] The commit summary should mention all merged revs [17:24:25] Let me generate that for you [17:24:51] You have a script for that too? [17:24:53] r99630, r99680, r100021, r100115, r100332 [17:24:57] The same user JS thing [17:25:00] nice [17:25:08] I'll dig it up so I can share it with you [17:25:22] what else do you usually write in the commit message? [17:25:23] Krinkle refactored it but broke it, so I kept poking it until it worked again and then forgot about it [17:25:30] 1.18wmf1: MFT r99630, r99680, r100021, r100115, r100332 [17:25:49] okay [17:25:52] I'll use that [17:26:47] Alright [17:27:01] Now ssh into fenari and cd to /home/wikipedia/common/php-1.18 [17:27:44] I haven't done this before, is it just fenari.w.o? [17:27:46] And run svn up. This will take a while, because NFS sucks. I usually try to only svn up a specific directory or something but that seems kind of hard for this specific deploy [17:27:48] Yes [17:28:39] running [17:28:59] a while is like five minutes or more? [17:29:18] can be if you do extensions et al... [17:29:26] RoanKattouw: is it supposed to ask password for svn? [17:29:42] No [17:29:52] You probably don't have your agent forwarded then [17:29:59] Log out of fenari, and ssh back in using ssh -A [17:30:03] it's not forwarded by default [17:32:50] RoanKattouw: that was fast [17:33:10] Did it update your changes and nothing else? [17:33:19] yes [17:33:27] (Sometimes people commit stuff to 1.18wmf1 without deploying it and it'll just show up in a random person's svn up) [17:34:00] what to do if that happens? [17:34:24] Figure out which rev it is and yell at the committer [17:34:36] right [17:34:38] If they're not around, either review the rev and accept that you have to deploy it along with your own stuff, or revert [17:35:15] so, next step? [17:35:55] Your code is now live on test.wikipedia.org [17:36:33] So you'll want to briefly test its sanity there [17:36:42] Insofar as that is practical [17:37:17] (BTW, and this is probably unrelated, I'm seeing 1 PHP Fatal error: Cannot unset string offsets in /usr/local/apache/common-local/php-1.18/includes/GenderCache.php on line 105 , one occurrence in the logs of the past few minutes or so) [17:37:45] hmm [17:37:52] long long time since I touched that code [17:38:23] anyway, tested what I can [17:39:23] Alright [17:39:30] Then run scap 'Log message here' [17:39:46] And sit back and watch while all sorts of things happen on your screen for the next few minutes [17:39:52] scary [17:40:02] should I just write 'i18ndeploy', is that enough? [17:41:27] Yeah that's fine [17:41:41] Or mention the revid of your 1.18wmf1 merge, I gues [17:41:43] s [17:41:44] usually the also include the revision number [17:41:52] Yeah scap /used/ to do that automatically [17:41:57] But het deploy killed that [17:42:24] interesting [17:43:29] ssh errors are normal, right? [17:43:51] For a few servers, yes [17:44:03] You'll get a half dozen or so "Connection timed out" or "No route to host" errors [17:44:10] saw something like six + six [17:44:17] If you run scap, you'll get a fucktonne of random errors [17:44:22] sync-file not so much [17:44:28] scap is noisier, yes [17:44:37] You shouldn't see too many errors from scap these days [17:44:48] tias [17:44:53] But it'll still flood your screen with all sorts of output [17:45:04] so if scap floods so much, isn't it hard to spot any real errors? [17:45:16] Yes :( [17:45:28] now it says Finished [17:45:32] Yeah [17:45:38] Your code should be live site-wide now [17:45:57] yay [17:46:05] This is usually the point where I launch fatalmonitor to see if stuff is exploding (in terms of PHP fatals) [17:46:14] can I use that too? [17:46:19] Yes [17:46:25] it's just a command? [17:46:28] fatalmonitor should be in your $PATH on fenari, I believe [17:46:32] It's in /home/wikipedia/bin [17:47:29] nice [17:47:45] you probably get so many fatals it's not useful to get notification of them all [17:49:18] that's all? [17:49:29] Yeah that's it [17:49:38] that's wasn't so bad [17:49:50] Most deployments are uneventful [17:49:53] Except for the ones that aren't [17:50:01] I remember the Incubator deploy [17:50:16] although, I didn't break anything, so I may not know how to fix it if I do [17:50:35] That was a typical case of merging modern code into an ancient branch (1.17wmf1) resulting in incompatibilities that threw fatals and had to be fixed up, etc etc [17:51:11] If you break something it's usually a MediaWiki-side thing that isn't very WMF-specific [17:51:20] "usually" [17:52:57] Yeah, except if it's not :D [17:53:05] You didn't expect it to be simple, did you? (tm) [17:53:35] Anyway, if things break post-deploy, you should try to see if you can diagnose them yourself first, and if not you can try just reverting your deployment [17:53:46] (This means you should not disappear shortly after deploying code) [17:53:58] If you can't figure it out and no one is on IRC, you call someone [17:54:10] Phone numbers are on [[office:Contact list]]. You should put yours on there too [17:54:42] right [17:57:36] Also, if you haven't already, read [[wikitech:How to deploy code]]. There are additional things you need to know when it comes to changing configuration files and installing new extensions [17:57:46] (and read the pages linked from it as well) [17:59:58] I think I've seen that [19:11:29] Reedy: do you know where this message, "Scripts should use an informative User-Agent string with contact information, or they may be IP-blocked without notice." comes from? [19:11:43] preilly, squid [19:11:52] Do you get only that? [19:44:51] No, it comes from wmf-config/checkers.php [19:44:59] Or well, maybe not that exact string [19:45:10] There is *something* that detects empty or uninformative UAs in checkers.php [21:03:08] http://thedailywtf.com/Articles/The-Query-of-Despair.aspx [22:14:29] Reedy: yikes [22:14:52] lolol [22:40:07] good night :) [23:04:43] hello howief [23:44:21] hey Danny_B|backup