[00:37:14] hexmode: ping [00:38:42] neilk_: pong [00:38:56] hexmode: just looking for some simple bugs to give to our new devs [00:39:10] hexmode: it's kind of difficult to find a bug that anyone can fix... :) [00:39:55] neilk_: "annoying little bugs" page on mw.o is the place sumanah and I have been working on [00:40:23] hexmode: oh, I forgot about that. Thanks [00:55:40] grrrr. restoring from time machine has annihilated my localhost webserver settings. [00:55:45] hexmode: none of those bugs are what I would call easy... [00:58:00] neilk_: noted... that's all I have ATM [00:58:23] neilk_: did you look at the "easy" tag ones, too? [00:58:27] yes [00:58:35] k [00:58:54] every time I look into it, it involves more learning than I want someone to have on their first day [00:59:30] or, alternatively, it's so trivial and in some obscure thing (like Extension:RecordAdmin) it's not worth getting into [00:59:49] heh [01:00:19] what about this: https://bugzilla.wikimedia.org/show_bug.cgi?id=25909 [01:00:41] it may be a matter of applying the patch, but it's also on a VERY important page. [01:01:43] neilk_: if you want to look at patches try searching "patch, need-review" [01:01:52] *tons* in there [01:01:58] no, I only found that because it was tagged easy [01:01:59] and, yes, a good way to learn [14:22:20] Nikerabbit: You ready to do the LU debugging thing? We can do it in a shared screen session if you like [14:26:53] RoanKattouw: oh yes [14:27:11] with what cover channel? [14:27:25] screen(1) has multiuser support [14:27:35] but does it have chat? [14:27:42] But it only works either if screen is setuid root (which is not), or if one of the users attaches as root [14:27:43] No [14:30:15] so? [14:32:39] OK I just got the green from Mark to do it this way [14:32:47] SSH into fenari and run 'screen' [14:33:55] ( Nikerabbit ) [14:34:04] We can chat here, or in one of the screens [14:34:16] there [14:34:22] I mean [14:34:24] did that [14:34:39] irc is probably easier [14:35:30] OK do Ctrl-A : multiuser on [14:35:43] (So that's Ctrl-A, colon, 'multiuser on', return) [14:35:57] done [14:36:11] access denied it says [14:36:14] Yeah [14:36:21] Try Ctrl-A : acladd root [14:36:40] try again [14:38:07] OK that worked [14:38:17] Now, to your bug report [14:38:19] https://ta.wikipedia.org/wiki/%E0%AE%AE%E0%AF%80%E0%AE%9F%E0%AE%BF%E0%AE%AF%E0%AE%BE%E0%AE%B5%E0%AE%BF%E0%AE%95%E0%AF%8D%E0%AE%95%E0%AE%BF:Narayam-more-imes WFM [14:38:52] you see "More input methods" ? [14:39:49] When I visit that URL I see ??????????????????????????? ???????????????????????? ????????????????????? [14:40:48] something made it change in the last minute [14:41:00] on the first load I got it in English, on the seconds it's in tamil [14:41:14] if you hover the input tools menu, what do you see? [14:41:23] the second last item with arrow [14:41:27] "more input methods" [14:41:29] rawr [14:41:35] hmm [14:41:47] Maybe this is the message blob cache [14:41:52] *RoanKattouw clears it [14:42:07] RoanKattouw: did you do action=purge or anything to that page in mediawiki:namespace? [14:42:27] No [14:42:37] I don't understand why it would suddenly change right now then [14:43:11] Hmm, maybe a server is out of sync [14:44:19] yep [14:44:25] if I reload enough I see it in English [14:45:49] srv199 says the page source, but does that mean anything? [14:45:59] I'm logged out, so shouldn't it be in squid cache? [14:46:24] I do have some cookies though [14:47:10] Hah, look at the screen [14:47:14] yup [14:47:29] (I'm sorry for trashing around so much, I had trouble getting the command right) [14:48:00] dsh is distributed ssh? [14:48:10] Yes [14:48:18] Let me explain that command line in the shell itself [14:50:36] and how about this MWScript.php? [14:51:06] Oh, that's the het deploy thing for running maintenance scripts [14:51:20] Normally, you run maintenance scripts with mwscript eval.php tawiki [14:51:33] /usr/local/bin/mwscript is a convenience wrapper that's not available on the Apaches [14:51:46] I cat-ed it out in the shell [14:52:50] which script processes the tawiki argument? [14:53:46] That's some weird magic [14:54:00] eval.php tawiki is a shorthand for eval.php --wiki=tawiki [14:54:19] is that for all maintenance scripts or just eval? [14:54:24] MWScript.php inspects the --wiki argument to decide from which dir the maintenance script should be run, then the maintenance script receives and processes the argument as well [14:54:27] All [14:54:57] https://wikitech.wikimedia.org/view/How_to_run_a_maintenance_script [14:55:30] is it only me who gets bothered by the expired cert warning? [14:55:42] I must have it whitelisted [14:55:45] The issue is known [14:56:01] Hmm alright so I am going to re-run l10nupdate and see what happens [14:56:07] okay [14:56:09] With all the puppet changes it might just be broken [14:56:36] Hmph [14:56:49] Not all the changes have been deployed yet apparently [14:57:04] ? [14:57:28] Ryan merged my LU changes into the 'test' branch, but not into the 'production' branch [14:57:35] *RoanKattouw makes mental note to ambush Ryan later [14:57:43] again :/ok [14:58:43] Although, wait [14:58:49] It's probably somethnig in the sync script [14:58:59] No point waiting half an hour for LU to run if I can just resync [14:59:14] Yeah there we go [14:59:19] Massive perms errors all over the place [15:00:41] I'll need to fix these perms errors as root [15:01:02] humn, I know srv###, what's mw##? [15:01:24] have seen* [15:01:30] "mw" is the new "srv" [15:01:36] Rob thought 'server' was too generic [15:01:49] So all new Apaches we've bought are named "mwNN" [15:02:09] All Apaches in eqiad are named "mwNNNN" with a number in the 1000-1999 range [15:02:35] eqiad is where? [15:02:39] Virginia [15:02:46] that's the new one? [15:02:57] It's an EQinix datacenter and the nearest airport is IAD (Washington Dulles) [15:02:59] Yes [15:03:17] I always wondered why those funny names [15:04:07] pmtpa is PowerMedium in Tampa [15:04:23] they are derived from airports [15:04:33] We also have sdtpa (don't know what sd is), knams (KennisNet in Amsterdam) and esams (EvoSwitch) [15:05:20] and had yaseo? [15:05:50] Yes [15:05:54] Yahoo in Seoul [15:07:02] Nikerabbit: Alright, perms should be fixed, re-running sync-l10nupdate [15:07:20] you did some magic [15:07:32] Well, magic [15:07:34] root@fenari:~# dsh -cM -g mediawiki-installation 'chown -R mwdeploy:mwdeploy /apache/common/php-1.18/cache/l10n' [15:07:58] do you know why they had the wrong perms in the first place? [15:08:15] I mean, I would expect if the server creates them on demand... [15:08:21] Bah, it's blocked on srv255 [15:08:26] No, I'm not exactly sure why [15:08:34] It's possible that one of my puppet changes didn't get deploye [15:08:35] d [15:08:47] I'll harass Ryan about getting all of my Puppet changes re LU deployed [15:08:56] Then if it's still broken, we can look at it again [15:09:29] is there some log where it is easy to check if it is broken? [15:09:30] *RoanKattouw aborts sync-l10nupdate because it's just waiting forever for srv255 to respond at this point [15:10:16] Unfortunately no :( [15:10:51] OK that looks better [15:10:53] see screen [15:11:30] enwiki? [15:11:54] Yeah, it's stupid, you have to put something in for a wiki name [15:11:59] It should really be a wiki-less script [15:12:15] (one where you don't have to specify a wiki) [15:12:16] and how fast I should see the effects? [15:12:25] 5-10 mins for JS [15:12:39] okay [15:13:28] is it varnish that holds the 5 min cache? [15:15:41] Both Varnish and your browser [15:16:39] browser cache I'm able to clean myself [15:16:45] Yeah [15:16:53] Ctrl+F5 after 5 minutes should work [15:20:17] should [15:20:30] I'm not seeing it yet [15:21:39] how can I create tags to test https://bugzilla.wikimedia.org/25909 [15:22:02] hexmode: I think abusefilter extension creates some [15:22:35] Nikerabbit: that's what I thought to, but after installing it and creating some with it, I couldn't see them with that patch [15:22:49] hmmph [15:22:55] exactly [15:23:18] I'm doing something wrong, but what? [15:23:33] *hexmode looks to Nikerabbit for all the answers [15:24:27] I don't know [15:24:32] Nikerabbit: Hmm, I may have to be more aggressive here and also touch the script file, although ideally I wouldn't have to [15:24:49] I'm not familiar with change tags yet [15:27:32] Oh, heh, clearMessageBlobs.php was being stupid and refused to clear blobs [15:28:04] huh? [15:28:14] Because of some timestamp value somewher [15:28:24] The script is stupid and assumes message changes only come from .i18n.php files [15:28:43] Needs to look at cache/l10n too [15:28:50] ah [15:28:51] I'll fix that soonish [15:28:54] the problem of sticky caches [15:29:08] I have few of those in Translate extension too [15:35:13] RoanKattouw: thanks, it seems to work [15:35:33] Yay [15:35:54] Would you mind fixing clearMessageBlobs.php ? [15:36:04] It would probably be good for you to know some things about LU as well :) [15:36:16] ooo [15:36:21] The change in clearMessageBlobs.php shouldn't be hard, it's just about also taking the timestamps of cache/l10n/*.cdb into account [15:37:03] whar is that script located? [15:37:05] The file is in /mediawiki/trunk/extensions/WikimediaMaintenance/clearMessageBlobs.php [15:37:35] The deployed version should be identical, but it's in a different location, /branches/wmf/1.18wmf1/maintenance/wmf/clearMessageBlobs.php [15:39:47] just one more loop I guess [15:40:17] RoanKattouw: what's the expected path to those files? [15:40:46] $IP/cache/l10n/*.cdb [15:40:59] No, wait [15:41:11] $IP/cache/l10n/*.cache [15:42:03] hmm [15:46:04] RoanKattouw: why is the script doing file_exists for files returned by glob? [15:46:13] hah [15:46:15] Is it? [15:46:22] So it is, that's weird [15:46:35] That's stupid, you can probably remove that [15:46:38] *RoanKattouw didn't write this [15:51:52] RoanKattouw: r102404... or should I have committed to the branch? [15:52:01] !r 102404 [15:52:01] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102404 [15:52:16] No, that's excellent, thanks [19:18:36] evenin [19:19:16] TimStarling: is there already a new date for vips deployment? [21:02:33] yo? [21:02:39] yo! [21:02:45] Yeah [21:02:49] *hexmode looks around [21:03:05] Reedy: here? [21:03:29] is TimStarling really here? [21:03:31] I'm still trying to verify that myself [21:03:38] he's marked as /away [21:03:38] anyway... lets look at revisions [21:04:32] did everyone get hashar's email? Lets ignore the ones he said he was going to look at [21:05:08] now... which ares are left: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/status/new?offset=92475 [21:05:32] dang, hate that list [21:05:34] note: I just fixed r101291 which was failing on translatewiki [21:05:43] it includes all the extensions [21:06:02] !r 101291 [21:06:02] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101291 [21:06:18] http://hexm.de/9h -- better [21:06:35] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.18?status=new < 8 more [21:06:53] !r 79845 [21:06:53] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79845 [21:07:24] "$wgMaxUploadSize may now be set to an array to specify the upload size limit ..." [21:07:36] ... [21:07:42] hrm... anyone for uploading? [21:07:44] oh [21:07:47] so....just to be clear on this list. I'm assuming all of these were marked "fixme" at some point, and then resolved [21:07:50] ... made it sounds nasty [21:08:32] robla: yes, I think so [21:08:51] those on this first list, the non-tagged ones, are pre-branch [21:09:18] So should we just pick the person who marked it fixme? [21:09:32] yeah, that makes sense [21:09:32] that'd be the easy way out [21:09:42] then we can just move on to the 1.18 ones [21:09:47] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.18?status=new [21:10:12] !r 94171 [21:10:12] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94171 [21:10:17] <^demon> r94171 is fine. [21:10:21] <^demon> Someone should mark it resolved. [21:10:38] heh... ok [21:10:56] !r 99307 [21:10:56] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99307 [21:11:41] "Add !important to the tablesorter indicator." [21:11:58] Krinkle: you here? is it ok? [21:12:13] r102297 is OK, I just marked it as such [21:12:27] hexmode: No, imho it's not ok. [21:12:27] Could be looked over by Krinkle but it looks fairly trivial to me [21:12:34] Perhaps a todo [21:12:48] ok, tag todo and mark ok [21:12:53] next! [21:12:56] Wouldn't call it a beta release blocker, I would consider it a blocker for the stable release. [21:13:10] I think this is the time when we look at blockers for the stable release [21:13:23] agreed [21:13:38] Oh, that commit does nothing but add !important. [21:13:43] Revert would be easier then. [21:13:43] I think r99307 should just be reverted [21:13:49] nod [21:13:57] Your suggestion for more specific selectors isn't really relevant, either [21:13:57] Krinkle: can you revert it? [21:14:02] Cause this is about style="" [21:14:10] yup....let's at least remove the 1.18 tag and move on [21:14:18] !r 99316 [21:14:18] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99316 [21:14:33] "Make partial dates in XMP not have the ommitted fields fulled out to 1's (reported by AVRS on irc)." [21:14:55] RoanKattouw: True. Not though I wasn't suggesting to make the selectors more specific. [21:15:06] I was aiming at the use cases I see on wikis, not the one he named in his commit message [21:15:10] Krinkle: I guess it's now been implicitly agreed that you'll revert r99307, but if you don't want to I'll do it [21:15:38] The selectors in jq.tablesorter.css are already more speficic that 99% of what wikis have in their local css [21:15:48] due to the class name on [21:16:01] Yeah [21:16:07] I don't think r99316 needs to be backported [21:16:10] still inline style will override, but that's just how it is. We shouldn't override inline styling [21:16:14] Looks like that can just be reverted and forgotten about [21:16:28] robla: Agreed [21:16:31] RoanKattouw: OK [21:16:37] Without r99316 some minority of image metadata dates will look weird [21:16:48] "it looks weird" is not sufficient for emergency backporting [21:17:20] k, so next release ok, but no 1.18 tag needed [21:17:25] hexmode: I'll detag. next one? [21:17:48] !r 99369 [21:17:48] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/`e1 [21:17:54] oops [21:17:59] !r 99369 [21:17:59] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99369 [21:18:15] "Fix up makeLinkItem and makeLink: [21:19:04] Comment: "Also in here is a fix for a regression caused by the BaseTemplate code. The language_urls had a title on them pre-1.18 but because I had this code white-listing attributes the title="" was being stripped out of stuff in the language box in skins updated to use makeListItem. On a suggestion from another user I switched the code to blacklist stuff actually used rather than only allow... [21:19:06] ...a limited subset of attributes. " [21:21:03] Dantman: Around? [21:21:35] ...in a way, yet not [21:21:51] Dantman: Re https://www.mediawiki.org/wiki/Special:Code/MediaWiki/99369 , is only a small part of that a fix that should go in 1.18? [21:21:52] Depends if it's interesting enough to pull me away from work [21:22:06] We're discussing whether or not r99369 should be merged into the 1.18 branch at the last minute [21:22:29] whii [21:22:45] You tagged it for 1.18 (twice), with a comment of "Also in here is a fix for a regression blah blah blah" but it seems there's other non-urgent stuff going on too [21:23:13] Part of it's a fix that should go into 1.18, part of it's something that I should have put into 1.18 when I wrote that code [21:23:30] doesn't look very dangerous to me [21:23:39] I talked to Hashar and he said I shoud re-tag it with more information [21:24:38] RoanKattouw: how much trouble is it to merge all of it? or should we get a specific diff? [21:24:55] hexmode: Merge isn't the problem, reviwe is [21:25:22] right... at this point that is the same diff, but should have said so. [21:26:17] Well, so who's gonna review it? :) [21:26:33] I'll take it if no one else wants it :) [21:26:39] preilly: you just tagged a bunch of revs in MobileFrontend 1.18: did you mean 1.18wmf1 ? [21:27:12] hexmode: no, I meant 1.18 [21:27:38] !r 99840 [21:27:38] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99840 [21:27:41] preilly: you're saying we shouldn't release the 1.18 tarball until that stuff gets backported? [21:27:51] robla: no [21:28:04] that's pretty much what tagging 1.18 means right now [21:28:11] preilly: my bad [21:28:18] robla: I mean you not me [21:28:35] "Followup to r99653 (bug 31643) -- reenable client-side thumbnailing of SVGs on Special:Upload, with workaround for Firefox 7 regression" [21:28:36] robla: do you want me to remove the tag? [21:28:46] preilly: it would help right now [21:28:51] that's what preillying oneself means! ;-) [21:29:19] !r 99840 [21:29:19] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99840 [21:29:43] so, client-side thumbnailing on Special:upload [21:29:58] (and yes, preilly, what hexmode said...it would help) [21:30:24] r99840's merge reason is false [21:30:26] commenting [21:30:59] RoanKattouw: can you untag it, too? [21:31:15] next: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101802 [21:31:22] robla: they should be undone [21:31:31] "As a work around for bug 31944, don't extract tiff:YCbCrSubSampling from XMP." [21:31:32] thanx! [21:31:55] since we untagged 99316 can we untag 101802? [21:32:22] !r101802 [21:32:22] --elephant-- I don't know anything about "r101802". [21:32:24] !r 101802 [21:32:24] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101802 [21:32:54] "Its not critical by any means" [21:33:01] According to the commiter [21:33:03] +t [21:33:12] hi hashar, code review discussion re 1.18 is still going on [21:33:15] !1.18 [21:33:15] --elephant-- I don't know anything about "1.18". [21:33:33] sumanah: I send an email to mark with the work I did this morning :D [21:33:47] well the work that remains to be done after my work this morning :-))) [21:33:55] hashar: yes, they've used your mail as a basis for the discussion :) [21:34:03] good [21:34:09] please note I have avoided trolling :-D [21:34:26] finally: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102414 [21:34:27] I think most of the remaining issues are just matter of reaching a consensus [21:34:32] not much code issue [21:35:23] 102414 just casts to (array) to avoid a fatal, right, RoanKattouw? [21:35:33] not much to discuss there [21:36:12] Aye [21:36:36] hrm... I'm going to go look back at the pre-branch ones and mark them for the person who marked 'em fixme [21:36:49] if I see anything else I'll pop it up here [21:36:59] but I think we're through [21:37:01] yay [21:37:11] anyone have anything else for 1.18? [21:37:20] beta2!!! :D [21:37:45] heh [21:37:49] I have no idea if you have discussed 101291 yet (the last fix me in 1.18) [21:37:56] <^demon> *ahem* [21:38:00] it is an issue nikerabbit is having. I can't reproduce it [21:38:04] <^demon> Is anyone going to mark 94171 as resolved? [21:38:10] !r 94171 [21:38:10] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94171 [21:38:35] was? [21:38:53] Nikerabbit: I was talking to the parser bug you are experiencing on twn.net [21:39:15] hashar: platonides made a followup commit which fixes it [21:39:47] do we have any backports to take off the list? [21:39:58] ^demon: Done [21:40:05] Nikerabbit: would be great to add the follow up to r101291 so we can get it merged in 1.18 [21:40:09] <^demon> RoanKattouw: <3 [21:40:10] Nikerabbit: if you know it offhand [21:40:14] robla: only one left [21:40:18] !r 99369 [21:40:18] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99369 [21:40:24] hashar: Platonides said he fixed it, didn't he? [21:40:27] which I think RoanKattouw said he would take [21:40:34] Yes [21:40:35] on it [21:40:39] :) [21:40:45] hexmode: there's only one new one, but lots of "ok" ones still to backport, and even one "fixme" [21:40:56] Nikerabbit: r102440 :) [21:40:57] !r 101291 [21:40:57] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101291 [21:41:04] RoanKattouw: he did fix the issue :) [21:41:13] hashar: yep [21:41:27] !r 102440 [21:41:27] --elephant-- http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102440 [21:41:35] oh [21:42:33] robla: Marked r101291 as new [21:42:34] robla: ah, I see... [21:42:40] pulling up the 1.18 list [21:43:03] hashar: the cause was {{int:foo}} where foo contained a = header = [21:43:34] Reedy: do you untag them once they've been backported? [21:43:42] aparently not :( [21:43:48] Usually [21:43:54] I can't say 100% they have been [21:44:24] Reedy: oh, ok [21:44:41] then how does ~50 revs to backport feel? [21:45:15] I'd say r101291 is okay, since it comes with a parser test :) [21:45:22] <^demon> You can probably do some of them in batches. [21:45:33] indeed [21:45:36] the list doesn't look too bad [21:45:59] but I have to go zZZ before my head explodes, have a good triage :) [21:46:23] Nikerabbit: night! [21:46:29] I think Ariel offered to merge the export/xml esk stuff if needed/wanted [21:46:39] which is 9/47 revs [21:48:15] <^demon> Ask him to merge it to 1.18wmf1. Don't want to blow up his dumps. [21:48:24] <^demon> (I think most are also tagged for that) [21:48:36] indeed, 9 on both [21:48:49] anyone want to review http://www.mediawiki.org/wiki/Special:Code/MediaWiki/92279 [21:48:51] Reedy: assuming we don't add to the list, how long do you think that will take? [21:48:58] since bryan fixme'd himself [21:49:27] *Reedy wonders why siebrand is tagging merges to 1.18wmf1 with 1.18wmf1 themselves [21:49:28] <^demon> I think all of that has been cleaned up and has tests now. [21:49:59] 2 revs are still marked new.. [21:50:15] Reedy: Untag [21:50:24] well, no [21:50:27] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102440 [21:50:40] 5 new, even [21:50:41] Yes, Ariel has agreed to merge stuff himself if and when we ask him to [21:51:13] 3 [21:51:18] Blaaah [21:51:26] http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.18?status=new [21:52:13] r99369 is OK [21:52:28] the two others by Platonides fix a bug for nike [21:52:34] mmm [21:52:35] he confirmed it works on twn.net [21:52:46] If those are waiting on Tim to review, they can just sit as is for now [21:52:48] it is a parser bug that cause blank pages [21:53:07] but they can be postponed for RC1 / beta3 [21:53:56] now good luck writing the new RN :-) [21:54:15] heading bed. See you tomorrow [21:54:17] "Stuff changed. Stuff added. Stuff fixed" [21:54:24] that s about it :-)))) [21:55:20] We could start a "Will it merge?" YouTube channel [21:55:48] lol [21:56:17] "Warning, don't breath this; Merge conflicts" [21:57:12] "This commit contains substances that are known to the State of California to cause merge conflicts" [21:58:12] hehehe [21:58:16] <^demon> "Attempting svn merge." [21:58:37] <^demon> "Note. Nothing about the above line is intended to convey any actual success or failure of the merge" [21:58:59] <^demon> "Attempting to merge should be done at your own risk, and the SVN developers cannot be held liable for loss of data due to botch merges or Acts of God." [21:59:18]