[00:09:08] Moe_Epsilon: I disagree, but okay [00:09:28] We all have our opinions :p [00:19:48] o_O [00:19:51] * Jasper_Deng_conn got the above two lines twice [00:19:54] boy is Freenode laggy today [00:20:37] howdy! Can anyone delete Q1758780 and put the German site into Q1222322? [00:23:11] MichaelQ: {{done}} [00:23:11] How efficient, Moe_Epsilon! [00:23:18] thanks [00:23:35] and goodbye [00:24:11] he left before I could point to him RFD [00:24:13] :< [00:24:37] Moe_Epsilon: true :) [00:25:14] Vogone: whatever consensus is, it's not like I [00:25:19] I'm going to fight it [00:25:21] so :p [00:28:09] posting {{done}} is efficient? :O [00:28:10] How efficient, Vogone! [00:28:15] {{cn}} [00:28:18] 10[1] 10https://www.wikidata.org/wiki/Template:cn [00:29:29] apparently, Vogone :p [00:47:16] New review: Daniel Werner; "(1 comment)" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/51164 [01:30:32] Jasper_Deng: I will bring it over here, probably better [01:30:36] what you want is the ability to kill nasty accounts, so that goes into your block policy [01:31:05] sDrewth: well, we can't modify the block policy until the socking policy says we can, right? [01:31:32] your ability of where to act and how to guide goes into accounts polcy [01:31:35] policy [01:32:20] no, Jasper_Deng, not exactly IMO [01:32:43] it definitely feeds into your blocking policy [01:33:15] blocks are blocks, so blocking statements are not in accounts policy [01:33:43] your accounts policy should enable your admins to act and why they ay use blocks [01:33:46] *may [01:34:20] remember that accounts are universal [01:34:39] you can administratively just tell a person to not use an account [01:35:00] or limit them to one account without blocking [01:35:14] Those are sanctions the community can enact by consensus at any time [01:35:39] sure, which is the purpose of an account policy [01:35:57] I am not arguing against what you are trying to achieve, fully support it [01:36:08] Well, I don't know if the policy really needs a provision for that [01:36:34] sDrewth: also I did some reworking to expand the scope of legitimate accounts and mention that they are encouraged [01:36:57] I am arguing that you state numbers of principles that allow admins to act in accordance with other policies [01:37:47] one problem here is that there aren't many other policies, but that might also work to our advantage. I think an "in a nutshell" is optimal too. [01:37:49] you are tying your policies down too tight, and and making them linear [01:38:25] I guess the header however can be simplified to a statement of those three principles [01:38:26] policies overlap and interact, they are not linear, they shouldn'thave hard boundaries [01:39:49] sDrewth: so are you saying we should make provisions for socking blocks in our blocking policy? [01:40:05] absolutely [01:40:27] you give admins the ability to block problematic accounts [01:40:46] and evil socks surely falls into that category [01:41:02] I actually think it already has a provision for blocking socks b/c "Administrators may block user accounts or IP addresses: [01:41:03] harmless unused socks are not [01:41:04] *To prevent local abuse where a pattern of local abuse has been established.* [01:41:06] (emphasis mine) [01:41:47] yep, and you want to have the ability that where a CU is done, that you can proactively block others (if you so choose) [01:42:17] and that could be said to fall under that last (mostly) [01:44:11] Jasper_Deng: my challenge to you is to not term sockpuppet, and to think problematic, and then apply it to those statements made and see how it differs, or how it might differ [01:45:02] I'm a sockpuppeter.......of legitimate accounts [01:45:27] sDrewth: added a provision in HTML comment to the blocking policy. As for that, care to clarify? [01:45:53] ? [01:46:08] * sDrewth puts out velcrose landing pad for Reedy [01:47:13] sDrewth: I just added a mention of socking as a form of "local abuse" in an HTML comment, or so I thought, b/c translate extension is getting in the way [01:47:34] okay, understand now [01:48:57] gah I might as well give up on that [01:48:59] (technically) [01:49:26] do you suggest any changes for the socking policy itself? [01:49:41] * Jasper_Deng can't make the blocking policy change due to the translate extension bug [01:50:38] sure, and that is just wordsmithing anyway, not a change in intent [01:50:59] Jasper_Deng: the other thing, in a policy, never include procedural steps [01:51:25] keep policy tight, if it needs procedure, have it separate [01:51:57] think Act > Regulations > Codes of Practice (or whatever your country does) [01:52:14] "Act" is always hard to change [01:52:37] the thing is, where /else/ would we put the procedure? [01:52:43] Regulations give governance and deal with smaller breaches, easier but nevery easy to change [01:52:46] we don't have a formal anti-sock process yet [01:53:32] they derive [01:53:55] why are you so firmly wedged on "We need anti-sock" rule [01:54:15] ? [01:54:26] Set principle on how we have accounts/access here [01:54:38] well, if a policy is to be useful to users, people should be told how to apply it [01:54:42] Set principle on how we deal with bad accounts [01:55:18] (of which the heavy end is block policy) [01:55:48] but follows on from Undo, Revert, Discussions and Slaps with Trouts [01:57:16] Would you like me to point you to sociologist's work on Culture, and other research on Rules? [01:57:27] sure [01:58:06] sDrewth: by extension I'd think you'd hate enwiki's page on it in terms of the layout [01:58:37] on enwiki has become so rule-based and it is made worse by the rule-nazis [01:59:03] and their arbcom issues derive from their rules and input focus [02:00:30] hhm.... I can't find many places to interchange "sockpuppet" with "problematic account" without losing the required context [02:01:30] * Jasper_Deng changed two out [02:01:51] legoktm: hey [03:36:14] jem-: hi [03:36:15] its disabled right now [03:36:16] dont have time to fix a bug with edit conflicts [03:41:38] * legoktm pokes rschen7754 [03:41:46] huh? [03:42:24] I need help with reviewing https://www.wikidata.org/wiki/User_talk:Legobot/properties.js/requests [03:42:38] :/ [03:43:03] just make sure it's valid? [03:43:10] any admin can actually [03:43:32] wow mostly docu [03:44:04] legoktm: does it work for templates yet? [03:45:26] oh lookie [03:45:27] Jasper_Deng and lncabh are here. [03:45:28] review https://www.wikidata.org/wiki/User_talk:Legobot/properties.js/requests please : [03:45:29] ) [03:45:30] :)* [03:45:40] * Jasper_Deng is rather busy [03:46:20] because somebody just tried to file a request for that [03:53:49] yeah [03:54:10] so it does work? [03:54:31] * Jasper_Deng_busy doesn't know how legoktm's process works, and has an essay to work on anyways [03:54:35] you can use Template:blah as a source [03:54:36] and it just runs on any mainspace page that transcludes it [04:03:35] oh rschen7754, one more thing, if it has over 2k pages to edit, add a |nolog=1 to the request when you copy it over [04:04:20] and dont approve anything over 5k pages, i gotta fix some weird bugs with long runs [04:10:19] rschen7754: yup it will [04:10:20] Jasper_Deng_busy: you read the request, if it makes sense you copy it to the main properties.js page :) [04:10:21] very simple :P [04:11:25] oh, ok [05:10:46] New patchset: Aude; "Fix ref to undefined variable in dispatch changes" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55537 [05:24:22] New patchset: Aude; "Ensure wikibase-comment-update is handled as message" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55539 [05:26:03] New patchset: Aude; "Ensure wikibase-comment-update is handled as message" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55539 [05:32:20] New patchset: Aude; "Implement autosummaries for create claim [WIP]" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55540 [06:11:46] New patchset: Aude; "Implement autosummaries for create claim [WIP]" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55540 [06:21:44] Does User:Docu ever come on IRC? [06:21:57] not that I know of [06:22:45] hmm [06:22:46] ok [08:22:25] New patchset: Henning Snater; "Removing API interaction from snaklistview widget" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55543 [08:22:25] New patchset: Henning Snater; "(bug 44683) Fixed unserialization of qualifiers in claim serializer" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55544 [08:22:25] New patchset: Henning Snater; "(bug 44683) Implementing qualifiers in the JavaScript UI" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55545 [08:22:50] New patchset: Henning Snater; "(bug 44683) Removing API interaction from snaklistview widget" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55543 [08:23:00] New patchset: Henning Snater; "(bug 44683) Fixed unserialization of qualifiers in claim serializer" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55544 [08:23:05] New patchset: Henning Snater; "(bug 44683) Implementing qualifiers in the JavaScript UI" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55545 [09:07:38] New review: John Erling Blad; "(1 comment)" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/53381 [09:08:09] The test system is about to be updated! [10:10:44] DanielK_WMDE: poke [10:11:54] when running the dispatcher during the weekend, I got a system error (causing reboot) a few times [10:12:09] when i stopped the cron jobs, then no issues [10:12:18] 1Mar 23 13:30:01 hathor suhosin[5998]: ALERT - script tried to disable memory_limit by setting it to a negative value -1 bytes which is not allowed (attacker 'REMOTE_ADDR not set', file 'unknown') [10:12:40] don't know if/how it's related but it must be since the issue stopped when i stopped the cron jobs [10:14:28] DanielK_WMDE: hey, you there? [10:14:55] Denny_WMDE: to repeat, what i just posted [10:14:58] when running the dispatcher during the weekend, I got a system error (causing reboot) a few times [10:15:02] when i stopped the cron jobs, then no issues [10:15:06] 1Mar 23 13:30:01 hathor suhosin[5998]: ALERT - script tried to disable memory_limit by setting it to a negative value -1 bytes which is not allowed (attacker 'REMOTE_ADDR not set', file 'unknown') [10:15:19] i don't quite understand how it's related but it must be [10:15:33] that… error message sounds weird [10:15:45] yeah [10:15:46] i thought it would be related with https://bugzilla.wikimedia.org/show_bug.cgi?id=46476 but I wouldn't know how [10:15:53] me neither [10:16:09] that's how i kept getting kicked off of irc, because my system rebooted [10:16:37] a daemon seems definitely the way to go, but not sure how quickly it can be implemmented [10:18:06] do you know whether we use the suhosin extension on wmf? [10:18:12] no idea [10:19:12] can you check wheter your /etc/ühp5/cli/php.ini file has a line memory_limit = −1 ? [10:19:19] ok [10:21:03] Denny_WMDE: i do [10:21:13] it's different than my apache php limit [10:21:24] set that to the apache php limit [10:21:27] yep [10:21:30] and then let's see if that bug returns [10:21:34] see if it works [10:22:21] i have 3 cronjobs running at once [10:22:44] set to restart at staggered intervals [10:31:26] aude, Denny_WMDE: strange issue. i commented on the bug report. will investigate, but I don't have much to go on. [10:31:35] DanielK_WMDE: neither do i [10:31:55] * aude wait and see if i get kicked off of irc again [10:32:03] if i disappear, you know why [10:32:09] there are a few things that could be improved abotu the dispatcher. i'll update the documentation / add todos. [10:32:16] I think audes report and john's issue are different [10:32:19] ok [10:32:21] probably [10:32:27] might be [10:32:35] could just be with running 3 dispatchers at a time [10:32:51] but if process get stuck and retain resources, especially file handles, that may explain system crashes [10:32:57] yeah [10:32:58] i.e. ignore Aude's comment on the bug report, DanielK_WMDE . John's bug report as it is, that would be my question, is it valid? [10:33:02] pretty much anything on *nix needs a file handle. hogging them is bad. [10:33:08] it took hours for it to happen [10:33:12] but happened several times [10:33:37] yes, but it is very likely not due to the db connections, which is the report about [10:33:40] and then i got tired of being kicked off of irc, so stopped the cron jobs [10:33:44] agree [10:34:04] Denny_WMDE: johns report of process gettign stuck and retaining database connections? I don't know why or how that would happen, but can't rule it out. I need more info about his exact setup and the exact symptoms and the failure mode. [10:34:12] DanielK_WMDE: ps, if you have time, helping with the terms table would be great [10:34:14] Denny_WMDE: db connections need file handles. [10:34:19] so it *might* be related [10:34:25] i've been working on autosummaries since yesterday, although won't be done today [10:34:44] aude: what have you been doing with autosummaries? [10:34:55] DanielK_WMDE: create and remove claims [10:35:15] where and how? [10:35:44] i mean - have you been changing stuff in the API modules, or on the client? [10:36:02] I think the first step should be to use the same localization mechanism on the repo and the client. [10:36:07] i'm trying to create a generalized way of creating summaries, based on $snak or whatever appropriate input [10:36:12] in the api to start [10:36:27] agree about using same mechanism [10:36:51] hm... i'm not sure that's a good idea. john has been working on somethign like that (for the maintenance script for rebuilding summaries), and ran into issues [10:37:00] huh? [10:37:23] the "generalized based on snaks" thing [10:37:33] there's general code that can be in common, small parts [10:37:59] if there's stuff that can be re-used, great. [10:38:08] i don't know about 100% generalization agree... [10:38:22] already differences for removing and creating claims [10:38:32] it's just difficult to write code that would generate summaries for any kind of change, based on a diff or something. the summary generally needs to be constructed programmaticaly be the code that actually performs the change. [10:38:34] stuff about formatting snaks, we're doing that in the client, claim diffs, etc [10:38:41] i have asked jeblad about https://bugzilla.wikimedia.org/show_bug.cgi?id=46476 and he said that the dispatcher script keeps the connections to the db open and does not release them. [10:38:53] those parts, we can eliminate some duplicate code [10:39:12] Denny_WMDE: i want to see how he gets to that conclusion, and what exactly he runs when that happens. [10:39:17] i asked him to write down how he stumbled on it, and he will write an email about it. i hope that gives us some insight [10:39:18] i asked for that info on the bug report [10:39:20] agree about general summaries [10:39:46] * aude tired of duplicating code for formatting parts of snaks, though :) [10:40:06] aude: ok. can you post your code to gerrit as WIP? I'd like to have a peek, to make sure we are working along the same lines. [10:40:13] DanielK_WMDE: already did [10:40:20] it's very much WIP [10:40:21] oh, great, thanks! [10:40:26] will have a look. dispatcher first, though [10:40:27] only adding claims, so far [10:40:52] removing claims is in progress [10:41:20] * aude go through each piece and then eliminate duplicate code when possible [10:41:34] and then use the same mechanism to handle comments in the client [10:41:44] as much as it can be the same [10:42:24] there's also weirdness about formatting comments.... they format differently in the article history vs. recentchanges [10:42:42] jeblad: to clarify: if you use --max-time 600, and run the cron job every 10 minutes, the script is *supposed* to stay alive for 10 minutes, and keep the db connection for that long. Only after 10 minutes (and a few seconds), it will shut down and release the conenction. [10:42:47] Denny_WMDE: ---^ [10:42:52] maybe that's the confusion? [10:42:56] DanielK_WMDE: that's how i run my cron jobs [10:43:12] aude: and that's how it's intended to work. [10:43:14] not sure how i would notice john's issue but believe i've not had that [10:43:17] DanielK_WMDE: right [10:43:41] i'm suspecting that john just expected the script to terminate, and he got alarmed when it didn't. [10:43:51] could be [10:43:58] i want to know whether processes *actually* pile up and cause problems. [10:44:09] aude: are you seeing any pile up? [10:44:19] DanielK_WMDE: unrelated, i have a couple small patches for review before code freeze [10:44:27] DanielK_WMDE: i don't think so [10:44:29] ok, will look in a minute [10:44:46] https://gerrit.wikimedia.org/r/#/c/55537/ - don't think we hit this in production, but important [10:45:02] aude: would be great if you could check for any stuck processes and retained db connections, and report your findings on bugzilla. [10:45:05] https://gerrit.wikimedia.org/r/#/c/55539/ - make the comments in the client slightly less ugly [10:45:10] DanielK_WMDE: ok [10:45:14] tnx [10:45:38] https://gerrit.wikimedia.org/r/#/c/55539/ (with a big ugly todo--- to refactor the whole thing) [10:45:44] aude: btw, when messing with the autocmment format, keep in mind that we have to stay B/C to anything already in the database [10:45:52] DanielK_WMDE: absolutely [10:47:22] * aude intrigued to know that erik wrote a bunch of the comments code in core :o [10:47:29] it's a bit ancient [10:47:52] and delicate [10:48:57] "delicate" - nicely put :) [10:49:07] I'd have said "crufty" :P [10:50:50] heh [10:56:54] * aude keeps hitting the fatal error fixed in https://gerrit.wikimedia.org/r/#/c/55537/ [10:57:08] if someone can approve, that would be great [10:59:26] New review: Aude; "note @todo: https://bugzilla.wikimedia.org/45852 to have the repo site name as part of the i18n mess..." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55539 [11:00:28] aude: doh! why didn't I hit this while testing?! [11:01:33] Hallo. [11:01:41] I see that there's an "Add links" message in Wikibase-client - the wikibase-linkitem-addlinks message. [11:01:43] DanielK_WMDE: i think only certain code paths [11:01:48] It's not yet deployed anywhere, right? [11:02:10] aharoni: it is on test2 [11:02:18] for pages that are not connected to wikidata [11:02:33] the widget will go with that [11:03:48] aude: Thanks. Is the widget a part of the extension, or is it custom JS? [11:04:13] aharoni: part fo the extension [11:04:15] of [11:04:34] depending on performance issues, it may or may not be enabled on the wikipedias in the nexte deployment [11:04:39] but will be on test2 for testing [11:04:58] New review: Daniel Kinzler; "How did I not hit this while testing? doh!" [mediawiki/extensions/Wikibase] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/55537 [11:04:59] Change merged: Daniel Kinzler; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55537 [11:05:01] it will get slight improvements this evening on test2 [11:05:12] Cool, thank you. [11:05:33] A lot of people have been waiting for this for a very long time :) [11:05:50] we just need to have it load the required js on demand, and reduce the amount of required js (as much as is possible) [11:05:50] aude: merged your $table fix [11:05:53] DanielK_WMDE: thanks [11:06:07] hoo is working on that [11:06:09] * DanielK_WMDE still doesn't get how that sliped through [11:06:26] DanielK_WMDE: i didn't hit it on friday, but only with different types of changes or something [11:06:55] certainly i wouldn't have merged it, had i seen it :o [11:07:17] DanielK_WMDE: can you also approve https://gerrit.wikimedia.org/r/#/c/55539/ [11:07:21] then we can branch [11:08:19] and run tests [11:10:44] https://gerrit.wikimedia.org/r/#/c/55539/ [11:10:49] somebody please merge https://gerrit.wikimedia.org/r/#/c/55539/ :) [11:10:58] * aude threatens to self merge it [11:12:34] Change merged: Denny Vrandecic; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55539 [11:12:54] New review: Daniel Kinzler; "(1 comment)" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55539 [11:13:27] aude: hav a suggestion there [11:13:40] DanielK_WMDE: ok [11:13:58] aude, Denny_WMDE: please wait with the branching until i have verified the cause for john's issue.# [11:14:28] i think it's the one i mentioned in the mail; if so, it is a real problem, but only without --max-time, which is what we use in deployment. [11:14:49] DanielK_WMDE: i'll make your suggested change [11:14:56] cool [11:14:56] then you merge it and i branch [11:17:21] New patchset: Aude; "Improve handling of comment messages in client" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55557 [11:17:34] DanielK_WMDE: https://gerrit.wikimedia.org/r/55557 [11:17:49] it works fine and better [11:18:51] * aude self merging in 2 min if nobody else merges it [11:19:07] or comments on it [11:20:00] * aude ready to branch in a minute [11:20:00] New review: Denny Vrandecic; "Nicer and easier to understand, thx" [mediawiki/extensions/Wikibase] (master); V: 2 C: 2; - https://gerrit.wikimedia.org/r/55557 [11:20:01] Change merged: Denny Vrandecic; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55557 [11:20:06] thanks Denny_WMDE :) [11:22:47] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Wikibase.git;a=log;h=refs/heads/mw1.21-wmf12b [11:23:40] https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/Wikibase.git;a=shortlog;h=refs/heads/mw1.21-wmf12b [11:23:54] (to see what's in the branch since last week) [11:24:12] didn't we want to wait for DanielK_WMDE to see if he can deal with https://bugzilla.wikimedia.org/show_bug.cgi?id=46476 ? [11:24:30] sure, we can backport if he has a patch [11:24:34] ok [11:24:39] it would be good to start with testing [11:24:45] agreed [11:24:49] we need wmf12b repo with wmf11 client [11:25:07] and wmf12b repo with wmf12 client (no data inclusion) -- like enwiki [11:25:25] and wmf12b repo with wmf12 client (with data inclusion) -- those that will get it, such as test2 [11:27:36] DanielK_WMDE: so every few seconds or so, i see a bunch of simultaneous php processes [11:27:49] between my dispatchers and job runners [11:28:24] the number of processes varies somewhat [11:29:04] could be i hit just so many of them during the weekend at certain times that it caused crash [11:31:03] jeblad, aude, Denny_WMDE: verified john's issue: processes pile up if run without --max-time from cron, if there are no changes to dispatch. It's trying to reach the default number of passes (1 in case of one target wiki), but doesn't count "idle" passes with no changes dispatched. [11:31:16] if no changes happen, processes pile up. --max-time doesn't have the problem [11:31:21] patch to follow. [11:31:32] DanielK_WMDE: makes sense [11:31:48] so we won't hit it in production but good to improve the dispatcher for that scenario [11:31:50] thx for the quick verification [11:32:02] i suspect system instability because of file handle retention [11:32:19] aude, Denny_WMDE: i'd like to get the fix into the branch, just in case. [11:32:25] DanielK_WMDE: ok [11:32:49] Oh, nice! =) [11:33:26] jeblad: thanks for finding this [11:33:35] +1 [11:33:43] * aude never tested without max-time [11:33:48] should try all the options [11:34:10] As a general rule; it is nice to have jobs like this as daemons, but daemons have their own problems too [11:34:19] jeblad: that's what ops wants us to do [11:34:21] * jeblad wonder if daemons have nightmares [11:34:22] so we will do [11:34:29] jeblad: sure they do :o [11:35:32] Had to maintain a system once that used syncronized cronjobs.. :'( [11:36:40] New patchset: Daniel Kinzler; "(bug 46476) count idle passes against --max-pass." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55561 [11:36:41] Ah, one thing, when you fork daemons Ubuntu can try to restart the wrong process [11:37:01] Or not restart the child if it dies [11:37:07] Kind of stupid thing [11:37:54] jeblad: do demons dream of binary sheep? [11:38:36] New patchset: Daniel Kinzler; "(bug 46476) count idle passes against --max-passes" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55561 [11:38:49] * jeblad gets a backflash of ternary numbers [11:39:10] Our brain is using a ternary system, very .. weird.. [11:39:31] * jeblad wonder if some of us uses more ternary numbers than others [11:39:47] 0, 1 and maybe [11:40:09] DanielK_WMDE: aude: should the fix still go into the branch? [11:40:16] Tobi_WMDE: yes [11:40:19] ok [11:40:28] aude: will you put it in? [11:40:30] jeblad: even transistors have 3 states: on, off and broken. [11:40:44] someone needs to test the patch and merge it [11:40:44] 8) [11:41:27] An off-transistor (in low inversion) is a fun topic, I can talk alot about that! :) [11:42:00] aude: it's best tested by running the script while there are no paneding changes. when run with no parameters, the script used to not terminate until a changes was made [11:42:25] ok [11:42:40] now, it should terminate immediately (in case of 1 target wiki) or after sleeping --max-passes -1 times. [11:42:46] oki [11:42:48] ok [11:43:06] ok, i am going off. if there is anything, you know how to reach me. cheers! [11:43:10] afk for lunch, call me if urgent [11:43:17] ok [11:51:46] "Call me if it breaks and you don't know how to fix it?" :) [11:52:03] heh [11:53:17] New patchset: John Erling Blad; "(Bug 43994) New Special:UnconnectedPages" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/53381 [11:55:19] Off to find something dead to eat.. [11:59:55] /me always assumed jeblad preferred to eat things alive... [12:00:20] odder: more like "call me if i broke it" :P [12:03:15] DanielK_WMDE: I see :) [12:15:26] New patchset: Daniel Kinzler; "Improve default and parameter docu for dispatcher." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55564 [12:15:38] New patchset: Daniel Kinzler; "Improve default and parameter docu for dispatcher." [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55564 [12:48:44] New patchset: Henning Snater; "(bug 44683) Implementing qualifiers in the JavaScript UI" [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55545 [12:48:47] APIError: parseerror: failed to deserialize [12:56:51] New review: Daniel Kinzler; "(9 comments)" [mediawiki/extensions/Wikibase] (master) C: -1; - https://gerrit.wikimedia.org/r/53381 [13:04:54] Lydia_WMDE: ist "Die neue Seite konnte nicht erstellt werden, da sie bereits vorhanden ist. " als Fehler bekannt, obwohl die Seite nicht vorhanden ist? Nach dem 3. mal Klicken auf "Erstellen" konnte ich https://www.wikidata.org/wiki/Q8249663 anlegen [13:05:23] Raymond_: uhhhh - nein... - kannst du einen bug filen bitte? [13:05:27] das kling tnicht gut [13:05:29] Lydia_WMDE: alles klar [13:05:31] danke dir [13:11:16] Raymond_: I also experienced this bug a few days ago, can you share it's number? [13:11:20] its* [13:11:28] odder: one second [13:12:26] odder, Lydia_WMDE : https://bugzilla.wikimedia.org/show_bug.cgi?id=46535 [13:12:34] \o/ [13:12:36] thx [13:12:41] you are welcome :) [13:13:03] Lydia_WMDE, Raymond_: at a wild guess: slave lag issue [13:13:29] strange..... [13:13:51] DanielK_WMDE: and at a tame guess? [13:14:06] odder: ...it's something else [13:14:09] my wild guess was wrong [13:14:20] or at least: the cause isn't as simple as i hoped [13:14:27] it might still be slave lag, somehow [13:14:50] the error message shown is from core, not Wikibare repos [13:14:59] dunno if this info helps [13:15:46] slightly [13:18:41] aude: are you still testing the dispatcher stuff? [13:18:49] DanielK_WMDE: yes [13:19:02] ok... how is it holding up? [13:19:36] well, it says "Starting loop for 24 passes or unlimited seconds" [13:19:42] but seems to keep going more than 24 times [13:19:53] which do you intend? [13:22:36] DanielK_WMDE: nevermind [13:24:46] Change merged: Aude; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55561 [13:25:07] ب**ن فاهس مهبث [13:25:12] f**k this life [13:26:24] aude: you got me worried there for a minute :) [13:26:50] it's supposed to apply the count and time limits, and exit as soon as one of the limits is hit. [13:27:03] DanielK_WMDE: wrong branch :) [13:27:10] hehehe... [13:27:22] there's a small follow-up too, btw [13:27:28] that's what was "broken" and the patch is good [13:27:40] i was hoping that [13:27:41] Change merged: Aude; [mediawiki/extensions/Wikibase] (master) - https://gerrit.wikimedia.org/r/55564 [13:27:48] the followup will go in the branch [13:27:56] * aude backporting [13:30:24] New patchset: Aude; "(bug 46476) count idle passes against --max-passes" [mediawiki/extensions/Wikibase] (mw1.21-wmf12b) - https://gerrit.wikimedia.org/r/55575 [13:30:24] New patchset: Aude; "Improve default and parameter docu for dispatcher." [mediawiki/extensions/Wikibase] (mw1.21-wmf12b) - https://gerrit.wikimedia.org/r/55576 [13:31:02]