Re: [Wikidata] Greater than 400 char limit for Wikidata string data types

2016-09-16 Thread Stas Malyshev 
Hi!

> However, given that we now have such a well informed community with
> established practices and good quality checks, it seems unproblematic to
> lift the character limit. I don't think there are major technical
> reasons for having it. Surely, BlazeGraph (the WMF SPARQL engine) should
> not expect texts to be short, and I would be surprised if they did. So I
> would not expect problems on this side.

I don't think there should be much trouble in this department. Unless
one is literally trying to download megabytes of data or millions of
items from a query (which we are working on solution for, but not yet)
the size of the string doesn't matter much and there would probably be
no noticeable difference between 400 and 2K strings for most queries I
can think of. Searching within such strings won't probably work very
well but that's not the intent anyway, as I understand.

The only thing I can think of is that we now both store the whole item
as huge blob in the DB (and consequently load it in memory) so if we had
a lot of huge strings it may have negative performance impact. But I
don't think changing a property that is usually one per item from 400
bytes to 2K would change anything.

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T145757: N3Quoter should generate correct escapes for ASCII control characters

2016-09-16 Thread daniel 
daniel added a comment.
If the right github repo has the right web-hook set up, then it usually does. Unless it doesn't. But I don't think we have it set for the replicated repo.TASK DETAILhttps://phabricator.wikimedia.org/T145757EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, danielCc: gerritbot, D063520, Aklapper, Smalyshev, daniel, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T145868: "Headless value factory should not be asked for its namespace" error on IF() + BOUND()

2016-09-16 Thread Smalyshev 
Smalyshev changed the title from ""Headless value factory should not be asked for its namespace" error ( Wikidata Query Service)" to ""Headless value factory should not be asked for its namespace" error on IF() + BOUND()".
TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, Aklapper, Esc3300, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T145899: Path query for taxons times out

2016-09-16 Thread Smalyshev 
Smalyshev changed the title from "path query times out" to "Path query for taxons times out".
TASK DETAILhttps://phabricator.wikimedia.org/T145899EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T145868: "Headless value factory should not be asked for its namespace" error ( Wikidata Query Service)

2016-09-16 Thread Smalyshev 
Smalyshev triaged this task as "Normal" priority.
TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, Aklapper, Esc3300, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145868: "Headless value factory should not be asked for its namespace" error ( Wikidata Query Service)

2016-09-16 Thread Smalyshev 
Smalyshev added a comment.
Filed https://jira.blazegraph.com/browse/BLZG-2091, seems to be recent regression.TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, Aklapper, Esc3300, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145868: "Headless value factory should not be asked for its namespace" error ( Wikidata Query Service)

2016-09-16 Thread Smalyshev 
Smalyshev added a comment.
Also note that you can rewrite it as:

SELECT ?item ?host (bound(?host) as ?p1)
{
	?item wdt:P31 wd:Q3917681
	OPTIONAL {?item wdt:P17 ?host }
}

and that works.TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, Aklapper, Esc3300, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T145868: "Headless value factory should not be asked for its namespace" error ( Wikidata Query Service)

2016-09-16 Thread Smalyshev 
Smalyshev claimed this task.Smalyshev added a comment.
Wow never seen that one before. I guess we have a headless rider here... ;) Will investigate.TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, Aklapper, Esc3300, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145712: Statement counts from pageprops do not match actual ones

2016-09-16 Thread Smalyshev 
Smalyshev added a comment.
We don't have any fixed guarantees regarding when this will happen

This is a huge problem for using page props in SPARQL then, as we a) do not get correct props when edit is done and b) don't have any idea when the data is right or whether it's right in any particular moment.

The props that we use - sitelink count and statement count - are easy to calculate and available on edit, as far as I can see - why can't they be updated synchronously?TASK DETAILhttps://phabricator.wikimedia.org/T145712EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Multichill, hoo, Esc3300, Pasleim, thiemowmde, daniel, Aklapper, Smalyshev, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145757: N3Quoter should generate correct escapes for ASCII control characters

2016-09-16 Thread Smalyshev 
Smalyshev added a comment.
I thought packagist auto-updates when you push new tag? May depend on settings though.TASK DETAILhttps://phabricator.wikimedia.org/T145757EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: gerritbot, D063520, Aklapper, Smalyshev, daniel, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145757: N3Quoter should generate correct escapes for ASCII control characters

2016-09-16 Thread daniel 
daniel added a comment.
Note: this still needs a release, so wikibase starts using the new version. We'll probably have to poke packagist to pick up the new tag.TASK DETAILhttps://phabricator.wikimedia.org/T145757EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, danielCc: gerritbot, D063520, Aklapper, Smalyshev, daniel, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145899: path query times out

2016-09-16 Thread Smalyshev 
Smalyshev added a comment.
See also https://jira.blazegraph.com/browse/BLZG-2089TASK DETAILhttps://phabricator.wikimedia.org/T145899EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T145899: path query times out

2016-09-16 Thread Smalyshev 
Smalyshev triaged this task as "Normal" priority.
TASK DETAILhttps://phabricator.wikimedia.org/T145899EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T145899: path query times out

2016-09-16 Thread Smalyshev 
Smalyshev created this task.Smalyshev added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONThis query:

SELECT ?item ?taxonName ?taxonRank ?parentName ?parentRank ?higherParent WHERE {
  BIND("Rivasmartinezia" AS ?taxonName) .
  BIND(wd:Q34740 AS ?taxonRank) . # Genus
  BIND(wd:Q756 AS ?higherParent) . # Plantae
  ?item wdt:P225 ?taxonName .
  ?item wdt:P105 ?taxonRank .
  ?item wdt:P171/wdt:P225 ?parentName .
  ?item wdt:P171/wdt:P105 ?parentRank .
  ?item (wdt:P171)* ?higherParent .
}

Times out even though it has only one match for ?item (wd:Q26902704) and this:

ASK {
  BIND(wd:Q756 AS ?higherParent) . # Plantae
  wd:Q26902704 (wdt:P171)+ ?higherParent .
}

is fast.

See: https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team#SPARQL:_.28wdt:P171.29.2ATASK DETAILhttps://phabricator.wikimedia.org/T145899EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Aklapper, Smalyshev, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145898: Wikidata time DataType should emit HTML

2016-09-16 Thread Izno 
Izno added a project: Wikidata.
TASK DETAILhttps://phabricator.wikimedia.org/T145898EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: IznoCc: Izno, Aklapper, D3r1ck01, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T145898: Wikidata time DataType should emit HTML

2016-09-16 Thread Izno 
Izno edited the task description. (Show Details)
EDIT DETAILS...```

It should probably be something like:

13 November 2007It should probably be something like:


```
13 November 2007
```

Take into account [[https://www.w3.org/TR/html5/infrastructure.html#dates-and-times|dates and times]] in the W3C specification.TASK DETAILhttps://phabricator.wikimedia.org/T145898EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: IznoCc: Izno, Aklapper, D3r1ck01, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T145897: wbc_entity_usage doesn't consistently report properties

2016-09-16 Thread Halfak 
Halfak created this task.Halfak added a project: Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONIt looks like wbc_entity_usage shows properties referenced inconsistently.

Except from :en:Template:Infobox_OS

| data22 = {{{license|{{#property:p275}
| label23= Preceded by
| data23 = {{{preceded_by|{{{preceded by|}}
| label24= Succeeded by
| data24 = {{{succeeded_by|{{{succeeded by|}}
| label25= Official website
| data25 = {{#if:{{{website|}}}
  |{{#ifeq:{{{website|}}}|hide||{{{website|}}} }}
  |{{#if:{{#property:P856}}
 |{{URL|{{#property:P856
   }}
   }}

But a query of WBC entity usage (https://quarry.wmflabs.org/query/12568) shows P856 but not P275.  Why?  Is this a bug?TASK DETAILhttps://phabricator.wikimedia.org/T145897WORKBOARDhttps://phabricator.wikimedia.org/project/board/71/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: HalfakCc: Kjschiroo, Halfak, Aklapper, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread ReleaseTaggerBot 
ReleaseTaggerBot added projects: MW-1.28-release-notes, WMF-deploy-2016-09-13_(1.28.0-wmf.19), WMF-deploy-2016-09-20_(1.28.0-wmf.20).
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: ReleaseTaggerBotCc: Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Unassigned] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread hashar 
hashar removed hashar as the assignee of this task.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 311168 merged by jenkins-bot:
Avoid triggering SiteConfiguration lookup in JobQueueGroup::push()

https://gerrit.wikimedia.org/r/311168TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 311172 merged by jenkins-bot:
Avoid triggering SiteConfiguration lookup in JobQueueGroup::push()

https://gerrit.wikimedia.org/r/311172TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T143819: Data request for logs from SparQL interface at query.wikidata.org

2016-09-16 Thread AndrewSu 
AndrewSu added a comment.
Thank you @leila for the guidance on the process and next steps -- very helpful!  @I9606 and I will touch base to see how we want to proceed/prioritize from our end...TASK DETAILhttps://phabricator.wikimedia.org/T143819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: AndrewSuCc: Lydia_Pintscher, mkroetzsch, leila, debt, thiemowmde, Jonas, Smalyshev, AndrewSu, Aklapper, I9606, mschwarzer, Avner, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 311172 had a related patch set uploaded (by Aaron Schulz):
Avoid triggering SiteConfiguration lookup in JobQueueGroup::push()

https://gerrit.wikimedia.org/r/311172TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] Let's move forward with support for Wiktionary

2016-09-16 Thread Thad Guidry 
Daniel,

I wasn't trying to help solve the issues - I'll be quite now :)

​I was helping to expose one of your test cases :)​

'product' is a lexeme - a headword - a basic unit of meaning that has a
'set of forms' and those have 'a set of definitions'
  Here are some of its forms:
 1. product
 2. products
 3. producing
 4. production
 5. ...

​Here are some definitions against PRODUCT:
1. product - ​a commodity offered for sale.
2. product - a quantity obtained by multiplication of two or more
numbers
3. product - anything that is produced.

​But a thought just occured to me...
A. In order to model this perhaps would be to have those headwords stored
in Wikidata.  Those headwords ideally would not actually be a Q or a P ...
but what about instead ... L​  ?  Wrapping the graph structure itself ?
Pros / Cons ?

B.  or do we go with Daniel's suggestion of linking out to headwords and
not actually storing them in Wikidata ?  Pros / Cons ?

Thad
+ThadGuidry 
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Let's move forward with support for Wiktionary

2016-09-16 Thread Denny Vrandečić 
Yes, that definitively is one promising approach (and I hope that we would
make a rough impact analysis before deciding on it and implementing it,
once the structures and data are there).

I wonder if there are other approaches that are somehow more subtle. But I
cannot express what I am looking for, and maybe yours is already
sufficiently close to optimal.


On Fri, Sep 16, 2016 at 11:00 AM Daniel Kinzler 
wrote:

> Am 16.09.2016 um 19:41 schrieb Denny Vrandečić:
> > Yes, there should be some connection between items and lexemes, but I am
> still
> > hazy about details on how exactly this should look like. If someone could
> > actually make a strawman proposal, that would be great.
> >
> > I think the connection should live in the statement space, and not be on
> the
> > level of labels, but that is just a hunch. I'd be happy to see proposals
> incoming.
>
> My thinking is this:
>
> On some Sense of a Lexeme, there is a Statement saying that this Sense
> refers to
> a given concept (Item). If the property for stating this is well-known, we
> can
> track the Sense-to-Item relationship in the database. We can then
> automatically
> show the lexeme's lemma as a (pseudo-)alias on the Item, and perhaps also
> use it
> (and maybe all forms of the lexeme!) for indexing the item for search.  So:
>
>   from ( Lexeme - Sense - Statement -> Item )
>   we can derive ( Item -> Lexeme - Forms )
>
> In the beginning of Wikidata, I was very reluctant about the software
> knowing
> about "magic" properties. Now I feel better about this, since wikidata
> properties are established as a permanent vocabulary that can be used by
> any
> software, including our own.
>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T145757: N3Quoter should generate correct escapes for ASCII control characters

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 310918 merged by jenkins-bot:
Fix escaping \a and \v which should be numeric in n3/turtle

https://gerrit.wikimedia.org/r/310918TASK DETAILhttps://phabricator.wikimedia.org/T145757EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, gerritbotCc: gerritbot, D063520, Aklapper, Smalyshev, daniel, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T144923: Add special page to show entity usage in client

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 310580 merged by jenkins-bot:
Introduce Special:EntityUsage/Q#

https://gerrit.wikimedia.org/r/310580TASK DETAILhttps://phabricator.wikimedia.org/T144923EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Ladsgroup, gerritbotCc: Aklapper, Liuxinyu970226, Ricordisamoa, Edgars2007, Ainali, gerritbot, Lydia_Pintscher, thiemowmde, Jan_Dittrich, daniel, Ladsgroup, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145754: Non conform turtle syntax for RDF dump

2016-09-16 Thread Smalyshev 
Smalyshev added a comment.
Hmm good point. We need to dig up which characters are allowed then.TASK DETAILhttps://phabricator.wikimedia.org/T145754EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, daniel, Aklapper, D063520, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145754: Non conform turtle syntax for RDF dump

2016-09-16 Thread daniel 
daniel added a comment.
@Smalyshev what worries me is that some characters are apparently illegal in RDF, even if we can encode them in N3. https://www.w3.org/TeamSubmission/n3/#escaping says: Some escapes (\a, \b, \f, \v) should be avoided because the corresponding characters are not allowed in RDF.TASK DETAILhttps://phabricator.wikimedia.org/T145754EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, danielCc: Smalyshev, daniel, Aklapper, D063520, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T144923: Add special page to show entity usage in client

2016-09-16 Thread Ladsgroup 
Ladsgroup closed this task as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T144923EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: Aklapper, Liuxinyu970226, Ricordisamoa, Edgars2007, Ainali, gerritbot, Lydia_Pintscher, thiemowmde, Jan_Dittrich, daniel, Ladsgroup, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Unblock] T103091: [Task] research how to surface usage tracking data for editors

2016-09-16 Thread Ladsgroup 
Ladsgroup closed subtask T144923: Add special page to show entity usage in client as "Resolved".
TASK DETAILhttps://phabricator.wikimedia.org/T103091EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: daniel, Jan_Dittrich, thiemowmde, Lydia_Pintscher, gerritbot, Ladsgroup, Ainali, Edgars2007, Ricordisamoa, Aklapper, D3r1ck01, Izno, Psychoslave, Wikidata-bugs, aude, TheDJ, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145754: Non conform turtle syntax for RDF dump

2016-09-16 Thread Smalyshev 
Smalyshev added a comment.
Well, I'm not sure banning \n is good, esp. given we have something like P2559.

Also, of course, we couldn't represent Q815674 properly then. Not a huge loss, but still. Turtle seems to be fine with properly-encoded low code points, so I'm not sure whether we need to. No idea how other UI parts would react to \0 or if all other CPs are safe though.TASK DETAILhttps://phabricator.wikimedia.org/T145754EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: SmalyshevCc: Smalyshev, daniel, Aklapper, D063520, D3r1ck01, Thibaut120094, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] Let's move forward with support for Wiktionary

2016-09-16 Thread Daniel Kinzler 
Am 16.09.2016 um 20:11 schrieb Thad Guidry:
> Denny,
> 
> I would suggest to use https://en.wiktionary.org/wiki/product as that strawman
> proposal.  Because it has 2 levels of Senses.
>   3. Anything that is produced (contains 6 sub-senses)

Modelling sub-senses is a completely different can of worms. The proposed model
doesn't allow this directly (we try to avoid recursive structures), but it can
be done using statements.

Your example doesn't really say anything about how lexemes could be connected to
items as labels/aliases, which is, i believe, what Gerard and Denny were 
discussing.


My usage of "Sense" and "From" follows

which in turn follows the LEMON model .

Synsets are not directly modeled, but it's possible to construct them via
statements.

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Updated] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread gerritbot 
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Thibaut120094, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 311168 had a related patch set uploaded (by Aaron Schulz):
Avoid triggering SiteConfiguration lookup in JobQueueGroup::push()

https://gerrit.wikimedia.org/r/311168TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Thibaut120094, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] Greater than 400 char limit for Wikidata string data types

2016-09-16 Thread Daniel Kinzler 
Am 16.09.2016 um 19:38 schrieb Denny Vrandečić:
> Markus' description of the decision for the limit corresponds with mine. I 
> also
> think that this decision can be revisited. I would still advice for caution, 
> due
> to technical issues, but I am sure that the development team will make a
> well-informed decision on this. It would be sad if valid usecases could not be
> supported due to that.

I agree, but re-considering this will have to wait until we have a better
solution for storing terms. The current mechanism, the wb_terms table, is a
massive performance bottleneck, and stuffing more data in there makes me very
uncomfortable.

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Let's move forward with support for Wiktionary

2016-09-16 Thread Daniel Kinzler 
Am 16.09.2016 um 19:41 schrieb Denny Vrandečić:
> Yes, there should be some connection between items and lexemes, but I am still
> hazy about details on how exactly this should look like. If someone could
> actually make a strawman proposal, that would be great.
> 
> I think the connection should live in the statement space, and not be on the
> level of labels, but that is just a hunch. I'd be happy to see proposals 
> incoming.

My thinking is this:

On some Sense of a Lexeme, there is a Statement saying that this Sense refers to
a given concept (Item). If the property for stating this is well-known, we can
track the Sense-to-Item relationship in the database. We can then automatically
show the lexeme's lemma as a (pseudo-)alias on the Item, and perhaps also use it
(and maybe all forms of the lexeme!) for indexing the item for search.  So:

  from ( Lexeme - Sense - Statement -> Item )
  we can derive ( Item -> Lexeme - Forms )

In the beginning of Wikidata, I was very reluctant about the software knowing
about "magic" properties. Now I feel better about this, since wikidata
properties are established as a permanent vocabulary that can be used by any
software, including our own.

-- 
Daniel Kinzler
Senior Software Developer

Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Greater than 400 char limit for Wikidata string data types

2016-09-16 Thread Denny Vrandečić 
(in particular because I expect that character limit to have to change for
Wiktionary in Wikidata)

On Fri, Sep 16, 2016 at 10:38 AM Denny Vrandečić 
wrote:

> Markus' description of the decision for the limit corresponds with mine. I
> also think that this decision can be revisited. I would still advice for
> caution, due to technical issues, but I am sure that the development team
> will make a well-informed decision on this. It would be sad if valid
> usecases could not be supported due to that.
>
> On Fri, Sep 16, 2016 at 6:51 AM Markus Kroetzsch <
> markus.kroetz...@tu-dresden.de> wrote:
>
>> On 13.09.2016 11:39, Sebastian Burgstaller wrote:
>> > Hi all,
>> >
>> > I think this topic might have been discussed many months ago. For
>> > certain data types in the chemical compound space (P233, canonical
>> > smiles, P2017 isomeric smiles and P234 Inchi key) a higher character
>> > limit than 400 would be really helpful (1500 to 2000 chars (I sense
>> > that this might cause problems with SPARQL)). Are there any plans on
>> > implementing this? In general, for quality assurance, many string
>> > property types would profit from a fixed max string length.
>>
>> FWIW, I recall that the main reason for the char limit originally was to
>> discourage the use of Wikidata for textual content. Simply put, we did
>> not want Wikipedia articles in the data. Long texts could also make
>> copyright/license issues more relevant (though, in theory, a copyrighted
>> poem could be rather short).
>>
>> However, given that we now have such a well informed community with
>> established practices and good quality checks, it seems unproblematic to
>> lift the character limit. I don't think there are major technical
>> reasons for having it. Surely, BlazeGraph (the WMF SPARQL engine) should
>> not expect texts to be short, and I would be surprised if they did. So I
>> would not expect problems on this side.
>>
>> Best,
>> Markus
>>
>>
>> >
>> > Best,
>> > Sebastian
>> >
>> > Sebastian Burgstaller-Muehlbacher, PhD
>> > Research Associate
>> > Andrew Su Lab
>> > MEM-216, Department of Molecular and Experimental Medicine
>> > The Scripps Research Institute
>> > 10550 North Torrey Pines Road
>> > La Jolla, CA 92037
>> > @sebotic
>> >
>> > ___
>> > Wikidata mailing list
>> > Wikidata@lists.wikimedia.org
>> > https://lists.wikimedia.org/mailman/listinfo/wikidata
>> >
>>
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Greater than 400 char limit for Wikidata string data types

2016-09-16 Thread Denny Vrandečić 
Markus' description of the decision for the limit corresponds with mine. I
also think that this decision can be revisited. I would still advice for
caution, due to technical issues, but I am sure that the development team
will make a well-informed decision on this. It would be sad if valid
usecases could not be supported due to that.

On Fri, Sep 16, 2016 at 6:51 AM Markus Kroetzsch <
markus.kroetz...@tu-dresden.de> wrote:

> On 13.09.2016 11:39, Sebastian Burgstaller wrote:
> > Hi all,
> >
> > I think this topic might have been discussed many months ago. For
> > certain data types in the chemical compound space (P233, canonical
> > smiles, P2017 isomeric smiles and P234 Inchi key) a higher character
> > limit than 400 would be really helpful (1500 to 2000 chars (I sense
> > that this might cause problems with SPARQL)). Are there any plans on
> > implementing this? In general, for quality assurance, many string
> > property types would profit from a fixed max string length.
>
> FWIW, I recall that the main reason for the char limit originally was to
> discourage the use of Wikidata for textual content. Simply put, we did
> not want Wikipedia articles in the data. Long texts could also make
> copyright/license issues more relevant (though, in theory, a copyrighted
> poem could be rather short).
>
> However, given that we now have such a well informed community with
> established practices and good quality checks, it seems unproblematic to
> lift the character limit. I don't think there are major technical
> reasons for having it. Surely, BlazeGraph (the WMF SPARQL engine) should
> not expect texts to be short, and I would be surprised if they did. So I
> would not expect problems on this side.
>
> Best,
> Markus
>
>
> >
> > Best,
> > Sebastian
> >
> > Sebastian Burgstaller-Muehlbacher, PhD
> > Research Associate
> > Andrew Su Lab
> > MEM-216, Department of Molecular and Experimental Medicine
> > The Scripps Research Institute
> > 10550 North Torrey Pines Road
> > La Jolla, CA 92037
> > @sebotic
> >
> > ___
> > Wikidata mailing list
> > Wikidata@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikidata
> >
>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T129037: Wikidata Query Service should provide a way to retrieve all items without a statement on a certain wiki

2016-09-16 Thread Multichill 
Multichill added a comment.
Thank you very much @Smalyshev . To complete this ticket, the original query:

https://tools.wmflabs.org/autolist/?language=nl=wikipedia=Motorfietstechniek=0===SELECT%20%3Fitem%20WHERE%20%7B%0A%20%3Flink%20schema%3Aabout%20%3Fitem%20.%0A%20%3Flink%20schema%3AisPartOf%20%3Chttps%3A%2F%2Fnl.wikipedia.org%2F%3E%20.%0A%20%3Fitem%20wikibase%3Astatements%200%20.%0A%7D=P=Run_manual=or_cat=and_wdq=not_wdqs=and_find=or_size=1

Getting pages in category tree... 263 pages found.

Getting corresponding Wikidata items... 263 items found.

Getting WDQS data... 131 items loaded.

Combining datasets...
After OR : 0 items.
After AND : 2 items.
2 items in combination.

Query took 0.44470715522766 seconds. 0.5 MB memory used.

Much faster!TASK DETAILhttps://phabricator.wikimedia.org/T129037EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, MultichillCc: Edgars2007, Jonas, Smalyshev, Nikki, Sjoerddebruin, hoo, Aklapper, Multichill, mschwarzer, Avner, debt, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, TheDJ, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T145880: Expose client entity usage via API in repos

2016-09-16 Thread Ladsgroup 
Ladsgroup created this task.Ladsgroup added projects: User-Ladsgroup, Wikidata.Herald added a subscriber: Aklapper.
TASK DESCRIPTIONWe need to have an API to expose wb_changes_subscription table in repoTASK DETAILhttps://phabricator.wikimedia.org/T145880WORKBOARDhttps://phabricator.wikimedia.org/project/board/2168/EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: daniel, Aklapper, Ladsgroup, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Reassigned] T145757: N3Quoter should generate correct escapes for ASCII control characters

2016-09-16 Thread daniel 
daniel reassigned this task from daniel to Smalyshev.daniel added a comment.
assigning to @Smalyshev, since he claimed the parent taskTASK DETAILhttps://phabricator.wikimedia.org/T145757EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, danielCc: gerritbot, D063520, Aklapper, Smalyshev, daniel, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145754: Non conform turtle syntax for RDF dump

2016-09-16 Thread daniel 
daniel added a comment.
This makes me wonder whether we should just disallow code points below U+0020 in all string input.TASK DETAILhttps://phabricator.wikimedia.org/T145754EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, danielCc: Smalyshev, daniel, Aklapper, D063520, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T145757: N3Quoter should generate correct escapes for ASCII control characters

2016-09-16 Thread daniel 
daniel claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T145757EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: danielCc: gerritbot, D063520, Aklapper, Smalyshev, daniel, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread Anomie 
Anomie added subscribers: aaron, Anomie.Anomie added a comment.
It looks like rMW6f9a246d25b2: Make JobQueueGroup::push() update the queuesHaveJobs() cache is what made job pushing start triggering T111441. It'll affect any code that pushes a job onto another wiki's job queue. @aaron might know if we could revert that patch until T111441 can be fixed, or if we can adjust the added code to only run if the job is being pushed on the local wiki.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, AnomieCc: Anomie, aaron, MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145858: [[MediaWiki:Wikibase-dispatchstats-intro/en]] i18n issue

2016-09-16 Thread Liuxinyu970226 
Liuxinyu970226 added subscribers: Lydia_Pintscher, aude, thiemowmde, Liuxinyu970226.Liuxinyu970226 edited projects, added MediaWiki-extensions-WikibaseRepository, Wikidata; removed MediaWiki-General-or-Unknown.
TASK DETAILhttps://phabricator.wikimedia.org/T145858EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Liuxinyu970226Cc: Liuxinyu970226, thiemowmde, aude, Lydia_Pintscher, Aklapper, Meno25, D3r1ck01, MuhammadShuaib, Izno, Psychoslave, Wikidata-bugs, Gryllida, Shizhao, Arrbee, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T145819: Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes

2016-09-16 Thread hashar 
hashar changed the title from "Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)" to "Jobs invoking SiteConfiguration::getConfig cause HHVM to fail updating the bytecode cache due to being filesize limited to 512MBytes".hashar removed a project: Patch-For-Review.hashar edited the task description. (Show Details)
EDIT DETAILSIncident report for some summary https://wikitech.wikimedia.org/wiki/Incident_documentation/20160915-MediaWiki

Summary
===

Some jobs such as **account creation**, **account rename** or **Wikidata dispatcher** invokes `SiteConfiguration::getConfig()` since they have to act on several wikis.  That method shells out to `mwscript maintenance/getConfiguration.php` with ulimits being applied, most notably a file size limit of 512MBytes.

However, when HHVM runs the command, it tries to update the byte code cache (either `/var/cache/hhvm/fcgi.sq3` or `/var/cache/hhvm/cli.sq3`). That causes a system error `EFBIG (File too large)` and the job fail.

See [[https://wikitech.wikimedia.org/wiki/Incident_documentation/20160915-MediaWiki incident report]] for actionables.

See below comments for debugging / technical details.



Original task
=

After pushing 1.28.0-wmf.19  to group1 (which includes wikidatawiki) the dispatch seems to have stopped entirelyTASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a subtask: T111441: SiteConfiguration::getConfig() does not work in Wikimedia production.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
I am enlarging the scope of this task. It is not just Wikidata but more about a variety of jobs that fails whenever shelling out to mwscript maintenance/getConfiguration.php.

Incident report is at https://wikitech.wikimedia.org/wiki/Incident_documentation/20160915-MediaWiki

(Huge thanks to @Addshore for the support/pointers etc)TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: MZMcBride, Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] Deleting properties / items in test.wikidata.org

2016-09-16 Thread Loic Dachary 


On 16/09/2016 15:54, Markus Kroetzsch wrote:
> Hi,
> 
> I don't think you need to worry at all about cluttering test.wikidata.org. I 
> guess it is purged regularly anyway.

Ok then, fine with me :-)

> Best,
> 
> Markus
> 
> On 14.09.2016 20:32, Legoktm wrote:
>> Hi,
>>
>> On 09/08/2016 08:54 AM, Loic Dachary wrote:
>>> Hi,
>>>
>>> But I was not able to figure out how to remove them afterwards, to not 
>>> clutter test.wikidata.org.
>>
>> You would just use the normal MediaWiki API delete feature[1]. Pywikibot
>> abstracts it as Page.delete(...).
>>
>> [1] https://www.mediawiki.org/wiki/API:Delete
>>
>> -- Legoktm
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
> 
> 
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata

-- 
Loïc Dachary, Artisan Logiciel Libre

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T144687: Change $wgArticleCountMethod in Wikidata from default ('link') to 'any'

2016-09-16 Thread Lydia_Pintscher 
Lydia_Pintscher added a comment.
I think the question hinges on is an item without a statement useful or not. Right now we have 2.75 Million of them of 23.8 Million items in total. That is quite a lot and we definitely need to get this number down. At the same time the number on the main page is incorrect and several times I had to correct people about it and had people complain to me about it.

So: Let's change it. Redirects should still not be counted but items without statements should be counted.TASK DETAILhttps://phabricator.wikimedia.org/T144687EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Urbanecm, Lydia_PintscherCc: Lydia_Pintscher, hoo, Liuxinyu970226, gerritbot, Matanya, JEumerus, Pasleim, Aklapper, abian, TerraCodes, Lewizho99, Maathavan, Urbanecm, D3r1ck01, MuhammadShuaib, Tulsi_Bhagat, Izno, Luke081515, biplabanand, Wikidata-bugs, Snowolf, aude, Shizhao, Mbch331, Jay8g, Krenair___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata] Deleting properties / items in test.wikidata.org

2016-09-16 Thread Markus Kroetzsch 

Hi,

I don't think you need to worry at all about cluttering 
test.wikidata.org. I guess it is purged regularly anyway.


Best,

Markus

On 14.09.2016 20:32, Legoktm wrote:

Hi,

On 09/08/2016 08:54 AM, Loic Dachary wrote:

Hi,

But I was not able to figure out how to remove them afterwards, to not clutter 
test.wikidata.org.


You would just use the normal MediaWiki API delete feature[1]. Pywikibot
abstracts it as Page.delete(...).

[1] https://www.mediawiki.org/wiki/API:Delete

-- Legoktm

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Greater than 400 char limit for Wikidata string data types

2016-09-16 Thread Markus Kroetzsch 

On 13.09.2016 11:39, Sebastian Burgstaller wrote:

Hi all,

I think this topic might have been discussed many months ago. For
certain data types in the chemical compound space (P233, canonical
smiles, P2017 isomeric smiles and P234 Inchi key) a higher character
limit than 400 would be really helpful (1500 to 2000 chars (I sense
that this might cause problems with SPARQL)). Are there any plans on
implementing this? In general, for quality assurance, many string
property types would profit from a fixed max string length.


FWIW, I recall that the main reason for the char limit originally was to 
discourage the use of Wikidata for textual content. Simply put, we did 
not want Wikipedia articles in the data. Long texts could also make 
copyright/license issues more relevant (though, in theory, a copyrighted 
poem could be rather short).


However, given that we now have such a well informed community with 
established practices and good quality checks, it seems unproblematic to 
lift the character limit. I don't think there are major technical 
reasons for having it. Surely, BlazeGraph (the WMF SPARQL engine) should 
not expect texts to be short, and I would be surprised if they did. So I 
would not expect problems on this side.


Best,
Markus




Best,
Sebastian

Sebastian Burgstaller-Muehlbacher, PhD
Research Associate
Andrew Su Lab
MEM-216, Department of Molecular and Experimental Medicine
The Scripps Research Institute
10550 North Torrey Pines Road
La Jolla, CA 92037
@sebotic

___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata




___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Commented On] T143819: Data request for logs from SparQL interface at query.wikidata.org

2016-09-16 Thread leila 
leila added a comment.
@AndrewSu Lydia and I had some off-list discussions and we thought it's a good idea that I leave a bit more information for you here:


Please don't spend days on the proposal if you decide to submit it. This is supposed to be a 1-2 page proposal that will help us understand what the problem is, why it's important and how you want to solve it (methodology). Some lit review would be great, but at a high level.



Dario and myself are operating at capacity in terms of forming new collaborations at the moment (we have a few more in the pipeline and we already have some in place). This being said, there are at least two other people in my team who may want to initiate this collaboration. Also, if the proposal ends up being aligned with something I will work on this year, I may drop something else to make it happen. This is to say that there is uncertainty on our end until we read the proposal, and there are some resource constraints.


I hope this extra information help you with your decision. If you have any question, please ping me.TASK DETAILhttps://phabricator.wikimedia.org/T143819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: leilaCc: Lydia_Pintscher, mkroetzsch, leila, debt, thiemowmde, Jonas, Smalyshev, AndrewSu, Aklapper, I9606, mschwarzer, Avner, Gehel, D3r1ck01, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata] Fwd: [Wikitech-l] Wikis back to 1.28.0-wmf.18 (was: Re: Upgrade of 1.28.0-wmf.19 to group 1 is on hold)

2016-09-16 Thread Amir Ladsgroup 
FYI

-- Forwarded message -
From: Antoine Musso 
Date: Fri, Sep 16, 2016 at 6:00 PM
Subject: [Wikitech-l] Wikis back to 1.28.0-wmf.18 (was: Re: Upgrade of
1.28.0-wmf.19 to group 1 is on hold)
To: 


On 14/09/16 23:05, Antoine Musso wrote:
> 
> For now. I am holding the train.  Will reassess tomorrow and ideally
> push group1 at 19:00 UTC then follow with group2 at 20:00UTC.
..
>
> Up-to-date status:
> https://tools.wmflabs.org/versions/
>
> MW-1.28.0-wmf.19 deployment blockers
> https://phabricator.wikimedia.org/T143328

Hello,

I have pushed 1.28.0-wmf.19 on thursday at 19:10 UTC. It quickly got
noticed that Wikidata was no more able to dispatch updates to the wikis
which is tracked in:

https://phabricator.wikimedia.org/T145819

This Friday, I was busy debugging the issue and did not notice a task
about account creation being broken:
  https://phabricator.wikimedia.org/T145839

As soon as I seen that, I have reverted to 1.28.0-wmf.18 at 12:50 UTC.

Account creation has been impossible from Thursday 19:10 UTC until
Friday 12:50 UTC.   Please pass the word around as needed.

My deep apologizes for not having found out earlier the impact was so
important.

I will write an incident report this afternoon with actionables.

--
Antoine "hashar" Musso


___
Wikitech-l mailing list
wikitec...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a project: Wikimedia-Incident.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: Tobi_WMDE_SW, FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, ArielGlenn, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb, mmodell___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T107595: [RFC] Multi-Content Revisions

2016-09-16 Thread Lydia_Pintscher 
Lydia_Pintscher removed a parent task: T91505: [Epic] Adding new datatypes to Wikidata (tracking).
TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, Lydia_PintscherCc: Pppery, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T91505: [Epic] Adding new datatypes to Wikidata (tracking)

2016-09-16 Thread Lydia_Pintscher 
Lydia_Pintscher removed a subtask: T107595: [RFC] Multi-Content Revisions.
TASK DETAILhttps://phabricator.wikimedia.org/T91505EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Lydia_PintscherCc: Swpb, ArthurPSmith, gerritbot, Smalyshev, Shrutika719, MGChecker, Sannita, Ricordisamoa, Liuxinyu970226, Rits, Physikerwelt, Lydia_Pintscher, Aklapper, AniaMag, mschwarzer, PuriDilip, Pahadiahimanshu, Manrajsinghgrover, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
From T145839#2643508 (task about Special:CreateAccount broken:



Sorry I took time to notice this bug was about Special:CreateAccount being broken.  I though it was just yet a random job failling due to T145819.  So I kept investigating that other task.

Eventually I have browsed the dashboard for authentication metrics at  https://grafana.wikimedia.org/dashboard/db/authentication-metrics?panelId=14  Screenshot of the last 24 hours shows a 100% error rate on account creation:

F4475252: accountcreation_error.png

I have reverted all wikis to 1.28.0-wmf.18 as a result which is reflected in the drop of errors at the far right of the graph above.

Sorry, should really have noticed that earlier.



All wikis are now back to 1.28.0-wmf.18.  The Wikidata dispatch lag is all fine  Account creation jobs are back as well.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T127213: [Bug] Merging doesn't always create a redirect

2016-09-16 Thread Esc3300 
Esc3300 added a comment.
I wonder if this fails because:


the check for the conflict doesn't always work correctly, but the merge still continues
the option(s) chosen for "ignoreconflicts" are forgotten somewhere during the process


When this is being fixed, maybe the feature T141845 could added as well.TASK DETAILhttps://phabricator.wikimedia.org/T127213EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Lydia_Pintscher, Esc3300, Magnus, matej_suchanek, hoo, Mbch331, Aklapper, Nikki, StudiesWorld, D3r1ck01, Izno, Wikidata-bugs, aude___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread Stashbot 
Stashbot added a comment.
Mentioned in SAL (#wikimedia-operations) [2016-09-16T12:50:09Z]  rebuilt wikiversions.php and synchronized wikiversions files: All wikis back to 1.28.0-wmf.18 :( T145819TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, StashbotCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 311120 merged by jenkins-bot:
All wikis back to 1.28.0-wmf.18

https://gerrit.wikimedia.org/r/311120TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 311120 had a related patch set uploaded (by Hashar):
All wikis back to 1.28.0-wmf.18

https://gerrit.wikimedia.org/r/311120TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread Stashbot 
Stashbot added a comment.
Mentioned in SAL (#wikimedia-operations) [2016-09-16T12:40:02Z]  Going to rollback all Wikis back to 1.28.0-wmf.18 . Despite much investigation, a bunch of jobs are broken due to T145819  which includes Special:CreateAccount :(TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, StashbotCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T91505: [Epic] Adding new datatypes to Wikidata (tracking)

2016-09-16 Thread Esc3300 
Esc3300 added a subtask: T107595: [RFC] Multi-Content Revisions.
TASK DETAILhttps://phabricator.wikimedia.org/T91505EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Swpb, ArthurPSmith, gerritbot, Smalyshev, Shrutika719, MGChecker, Sannita, Ricordisamoa, Liuxinyu970226, Rits, Physikerwelt, Lydia_Pintscher, Aklapper, AniaMag, mschwarzer, PuriDilip, Pahadiahimanshu, Manrajsinghgrover, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T107595: [RFC] Multi-Content Revisions

2016-09-16 Thread Esc3300 
Esc3300 added a parent task: T91505: [Epic] Adding new datatypes to Wikidata (tracking).
TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, Esc3300Cc: Pppery, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

2016-09-16 Thread daniel 
daniel added a comment.
@Pppery I'm refering to this mess: https://commons.wikimedia.org/w/index.php?title=File:L%C3%ADneas_de_Nazca,_Nazca,_Per%C3%BA,_2015-07-29,_DD_46.JPG="">.

Here's an overview of the use cases for MCR: https://www.mediawiki.org/wiki/Multi-Content_Revisions#Use_Cases.TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, danielCc: Pppery, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
Got a Failed to run getConfiguration.php. on mw1215.eqiad.wmnet:

$ ls -hl /var/cache/hhvm/
total 2.5G
-rw-r--r-- 1 www-data www-data 202M Sep 16 12:28 cli.hhbc.sq3
-rw-r--r-- 1 www-data www-data 2.3G Sep 16 04:10 fcgi.hhbc.sq3

That is from an api.php call.  If the file limit stands true, cli.hhbc.sq3 is only 202Mbytes so I am not sure why that fails.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T145868: "Headless value factory should not be asked for its namespace" error ( Wikidata Query Service)

2016-09-16 Thread Esc3300 
Esc3300 edited the task description. (Show Details)
EDIT DETAILS...SELECT ?item item ?host ?p1
{...TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Aklapper, Esc3300, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Edited] T145868: "Headless value factory should not be asked for its namespace" error ( Wikidata Query Service)

2016-09-16 Thread Esc3300 
Esc3300 edited the task description. (Show Details)
EDIT DETAILS...	?item wdt:P31 wd:Q3917681
	OPTIONAL {?item wdt:P17 ?host }  host }
	BIND(IF(!BOUND(?host), 0, 1) as ?p1)
  	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}...TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Aklapper, Esc3300, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T145868: "Headless value factory should not be asked for its namespace" error ( Wikidata Query Service)

2016-09-16 Thread Esc3300 
Esc3300 created this task.Esc3300 added a project: Wikidata-Query-Service.Herald added a subscriber: Aklapper.Herald added projects: Wikidata, Discovery.
TASK DESCRIPTIONSince yesterday, I keep getting this error in various queries.

Sample query:

SELECT ?item 
{
	?item wdt:P31 wd:Q3917681
OPTIONAL {?item wdt:P17 ?host }  BIND(IF(!BOUND(?host), 0, 1) as ?p1)
  	SERVICE wikibase:label { bd:serviceParam wikibase:language "en" }
}

The query for the riders and their horse list last updated on Sept 11 and fails now for the same reason.TASK DETAILhttps://phabricator.wikimedia.org/T145868EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Esc3300Cc: Aklapper, Esc3300, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145712: Statement counts from pageprops do not match actual ones

2016-09-16 Thread Esc3300 
Esc3300 added a comment.
This is probably an additional problem from last time.

In SQL, there were two problems:


some old items didn't have any page properties (this could be solved by purging items)
some items had "pp_value = "0" AND pp_sortkey is null" while most have "pp_value = "0" AND pp_sortkey = "0"' (this could not be solved by purging items)


BTW I added a chart and column for statement and sitelink counts to https://www.wikidata.org/wiki/Wikidata:Database_reports/Recent_deaths . It starts filling while some items do show a discrepancy.TASK DETAILhttps://phabricator.wikimedia.org/T145712EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, Esc3300Cc: Multichill, hoo, Esc3300, Pasleim, thiemowmde, daniel, Aklapper, Smalyshev, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread gerritbot 
gerritbot added a project: Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread gerritbot 
gerritbot added a comment.
Change 38 had a related patch set uploaded (by Hashar):
Inline doc for $wgMaxShell*

https://gerrit.wikimedia.org/r/38TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, gerritbotCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
On terbium cli.hhbc.sq3 was 876 MBytes. It is now down to 17 MBytes.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
Running:

sudo -u www-data /bin/bash /srv/mediawiki/php-1.28.0-wmf.19/includes/limit.sh '/usr/bin/php /srv/mediawiki/multiversion/MWScript.php maintenance/getConfiguration.php --wiki dewikinews --settings wgJobClasses --format PHP' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=50;MW_CGROUP=/sys/fs/cgroup/memory/mediawiki/job; MW_MEM_LIMIT=0; MW_FILE_SIZE_LIMIT=524288; MW_WALL_CLOCK_LIMIT=180'; echo "Exit code: $?"

WORKS on tin
FAIL on terbium

On terbium I then delete /var/cache/hhvm/cli.hhbc.sq3 and the command now pass.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T142906: Data access in user language doesn't obey the uselang get parameter

2016-09-16 Thread hoo 
hoo added a comment.

In T142906#2641437, @Jarekt wrote:
F4472286: New Picture (2).bmp

It is still not working right. I just set my preferred language to Polish and executed lua code with


mw.message.new( "lang" ):plain()
mw.message.getDefaultLanguage():getCode()

both returned "en" instead of "pl". At the same time call to message "{{int:lang}}" without LUA returns correctly "pl".



mw.message.* is not part of Wikibase, thus not affected by this. The changes mentioned here only affect the functionality to access data from the Wikibase repository (Wikidata) (mw.wikibase.*).TASK DETAILhttps://phabricator.wikimedia.org/T142906EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hooCc: gerritbot, Zppix, Jarekt, Geagea, Raymond, zhuyifei1999, aude, daniel, hoo, Zolo, Aklapper, D3r1ck01, Izno, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145712: Statement counts from pageprops do not match actual ones

2016-09-16 Thread hoo 
hoo added a comment.
Page props are always written (at least that's not known to be broken), but only in a job  (LinksUpdate) that runs asynchronously some time after the edit.

We don't have any fixed guarantees regarding when this will happen (only that it's happening after the actual edit gets applied).TASK DETAILhttps://phabricator.wikimedia.org/T145712EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, hooCc: Multichill, hoo, Esc3300, Pasleim, thiemowmde, daniel, Aklapper, Smalyshev, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T142691: [Bug] Terms table truncates labels exceeding 255 bytes, possibly leaving invalid UTF-8

2016-09-16 Thread Sjoerddebruin 
Sjoerddebruin added a comment.
Could be relevant: I was able to create a item with 810 characters (https://www.wikidata.org/wiki/Q26903397), but I can't add more labels with that length. https://www.wikidata.org/wiki/Q2732136#P734 shows the broken display as described in this ticket.TASK DETAILhttps://phabricator.wikimedia.org/T142691EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: thiemowmde, SjoerddebruinCc: Sjoerddebruin, gerritbot, aude, Jonas, daniel, Lydia_Pintscher, hoo, Lea_Lacroix_WMDE, Aklapper, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
I am trying in production now :(

OK mw1273, Jessie, 3.12.7+dfsg-1+wmf1

BAD terbium, Trusty, 3.12.7+dfsg-1+wmf1~trusty1TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
On the #beta-cluster-infrastructure

Trying with the ulimit at 512k

sudo -u www-data /bin/bash /srv/mediawiki/php-master/includes/limit.sh '/usr/bin/php /srv/mediawiki/multiversion/MWScript.php maintenance/getConfiguration.php --wiki wikidatawiki --settings wgJobClasses --format PHP' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=50;MW_CGROUP=/sys/fs/cgroup/memory/mediawiki/job; MW_MEM_LIMIT=0; MW_FILE_SIZE_LIMIT=524288; MW_WALL_CLOCK_LIMIT=180;'; echo "Exit code: $?"

OK deployment-mediawiki05, Jessie, HHVM 3.12.7+dfsg-1+wmf1
OK deployment-tin, Trusty, HHVM 3.12.1+dfsg-1~wmf2+trusty0

Upgraded HHVM on deployment-tin to 3.12.7+dfsg-1+wmf1~trusty1. It still write to the journal file and run fine.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T107595: [RFC] Multi-Content Revisions

2016-09-16 Thread Pppery 
Pppery added a comment.
Its really just a gut feeling that this is needless complexifying change. There is already a seperate TemplateData editor that can be accessed when you click the edit link for a template. And I'm not sure what series of nested templates for file license you are referring to.TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, PpperyCc: Pppery, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T107595: [RFC] Multi-Content Revisions

2016-09-16 Thread daniel 
daniel added a subscriber: Pppery.daniel added a comment.
@Pppery I guess what's more or less complicated is a question of perspective. Is embedding JSON-based template schemas in wikitext more or less complicated than managing them separately? Is it more or less complicated to have a separate, form based interface for file license info, instead of nested templates?

Do you have a specific concern, or is this just a gut feeling?TASK DETAILhttps://phabricator.wikimedia.org/T107595EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: brion, danielCc: Pppery, Florian, Liuxinyu970226, WMDE-leszek, Mholloway, Scott_WUaS, Niharika, MGChecker, LikeLifer, Elitre, Glaisher, JJMC89, RobLa-WMF, Yurik, ArielGlenn, APerson, TomT0m, Krenair, intracer, Tgr, Tobi_WMDE_SW, Addshore, Lydia_Pintscher, cscott, PleaseStand, awight, Ricordisamoa, GWicke, MarkTraceur, waldyrious, Legoktm, Aklapper, Jdforrester-WMF, Ltrlg, brion, Spage, MZMcBride, daniel, D3r1ck01, Izno, Luke081515, Wikidata-bugs, aude, jayvdb, fbstj, Mbch331, Jay8g, bd808___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
SiteConfiguration::getConfig() uses wfShellWikiCmd() to craft the command it uses the PHP interpreter from $wgPhpCli, that is '/usr/bin/php' which on terbium is hhvm.

549 $retVal = 1;
550 $cmd = wfShellWikiCmd(
551 "$IP/maintenance/getConfiguration.php",
552 [
553 '--wiki', $wiki,
554 '--settings', implode( ' ', $settings ),
555 '--format', 'PHP'
556 ]
557 );

Then the call is made. Note the comment about ulimit5.sh breaking the call !!!  The memory limit is set to zero explicitly :(

558 // ulimit5.sh breaks this call
559 $data = trim( wfShellExec( $cmd, $retVal, [], [ 'memory' => 0 ] ) );
560 if ( $retVal != 0 || !strlen( $data ) ) {
561 throw new MWException( "Failed to run getConfiguration.php." );
562 }
563 $res = unserialize( $data );
564 if ( !is_array( $res ) ) {
565 throw new MWException( "Failed to unserialize configuration array." );
566 }
567 $this->cfgCache[$wiki] = $this->cfgCache[$wiki] + $res;

A monkey patch would be to pass to wfShellExec the env 'filesize' => 0 to workaround the write to the HHVM cache file.

Unsolved

Why on 1.28.0.wmf-18 /var/cache/hhvm/cli.hhbc.sq3 is not updated/written to  but it is on 1.28.0.wmf-19.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145712: Statement counts from pageprops do not match actual ones

2016-09-16 Thread Multichill 
Multichill added a comment.
We had this before when we introduced new page properties. Shall I run a bot again to purge the affected items so everything is consistent again?TASK DETAILhttps://phabricator.wikimedia.org/T145712EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: Smalyshev, MultichillCc: Multichill, hoo, Esc3300, Pasleim, thiemowmde, daniel, Aklapper, Smalyshev, mschwarzer, Avner, debt, Gehel, D3r1ck01, Jonas, FloNight, Xmlizer, Izno, jkroll, Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a project: Beta-Cluster-reproducible.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added subscribers: JJMC89, FastLizard4.hashar merged a task: T145839: Account creation results in fatal MWException.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: FastLizard4, JJMC89, zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar edited projects, added HHVM; removed Patch-For-Review.
TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g, Joe, jeremyb___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
TLDR: when running mwscript on terbium the HHVM cache file /var/cache/hhvm/cli.hhbc.sq3 is committed to.  Sqlite3 then use the journaling system to rewrite it and that explodes due to the ulimit -f.TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
And strace is again my friend. Running it with:


-y to show file descriptor names
-e trace=desc for system calls related to file descriptor
-s 2048 for large strings


[pid 25957] open("/var/cache/hhvm/cli.hhbc.sq3", O_RDWR|O_CREAT|O_CLOEXEC, 0644) = 7
[pid 25957] open("/var/cache/hhvm/cli.hhbc.sq3-journal", O_RDWR|O_CLOEXEC) = 8

That is sqlite journaling.

[pid 25957] read(8, ..., 1024 ) = 1024
[pid 25957] lseek(7, 844421120, SEEK_SET) = 844421120
[pid 25957] write(7, ... , 1024 ) = -1 EFBIG (File too large)
[pid 25957] --- SIGXFSZ {si_signo=SIGXFSZ, si_code=SI_USER, si_pid=25957, si_uid=33} ---

[pid 25957] +++ killed by SIGXFSZ (core dumped) +++
[pid 25954] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_DUMPED, si_pid=25957, si_status=SIGXFSZ, si_utime=3, si_stime=22} ---

Command for copy pasting:
sudo -u www-data strace -y -e trace=desc -s2048 -f /bin/bash /srv/mediawiki/php-1.28.0-wmf.19/includes/limit.sh '/usr/bin/php /srv/mediawiki/multiversion/MWScript.php maintenance/getConfiguration.php --wiki dewikinews --settings wgJobClasses --format PHP' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=50;MW_CGROUP=/sys/fs/cgroup/memory/mediawiki/job; MW_MEM_LIMIT=0; MW_FILE_SIZE_LIMIT=524288; MW_WALL_CLOCK_LIMIT=180'; echo "Exit code: $?"

Without strace but with MW_INCLUDE_STDERR=1

/srv/mediawiki/php-1.28.0-wmf.19/includes/limit.sh: line 101: 24089 File size limit exceeded/usr/bin/timeout $MW_WALL_CLOCK_LIMIT /bin/bash -c "$1" 3>&-

TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread zeljkofilipin 
zeljkofilipin added a comment.

In T145819#2642193, @Addshore wrote:
2016-09-15 19:59:54 [139a37a9f227e562aefeee8d] terbium wikidatawiki 1.28.0-wmf.19 exception ERROR: [139a37a9f227e562aefeee8d] [no req]   MWException from line 561 of /srv/mediawiki/php-1.28.0-wmf.19/includes/SiteConfiguration.php: Failed to run getConfiguration.php. {"exception_id":"139a37a9f227e562aefeee8d"}


Maybe T145839 is related:

[V9vCrwpEFhUAADfGIToC] /wiki/Special:CreateAccount MWException from line 561 of /srv/mediawiki/php-master/includes/SiteConfiguration.php: Failed to run getConfiguration.php.
...TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hashar, zeljkofilipinCc: zeljkofilipin, Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
Reproduction on terbium invoking the command against dewikinews:

$ sudo -u www-data /bin/bash /srv/mediawiki/php-1.28.0-wmf.19/includes/limit.sh '/usr/bin/php /srv/mediawiki/multiversion/MWScript.php maintenance/getConfiguration.php --wiki dewikinews --settings wgJobClasses --format PHP' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=50;MW_CGROUP=/sys/fs/cgroup/memory/mediawiki/job; MW_MEM_LIMIT=0; MW_FILE_SIZE_LIMIT=524288; MW_WALL_CLOCK_LIMIT=180'; echo "Exit code: $?"
[Fri Sep 16 09:35:03 2016] [hphp] [7563:7f494d3c4100:0:01] [] Lost parent, LightProcess exiting
/usr/bin/timeout: the monitored command dumped core
[Fri Sep 16 09:35:03 2016] [hphp] [7564:7f494d3c4100:0:01] [] Lost parent, LightProcess exiting
/srv/mediawiki/php-1.28.0-wmf.19/includes/limit.sh: line 101:  7556 File size limit exceeded/usr/bin/timeout $MW_WALL_CLOCK_LIMIT /bin/bash -c "$1" 3>&-

Exit code: 153TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, zeljkofilipin, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
@Addshore wrote  https://logstash.wikimedia.org/goto/259821dc32242eb3fde0cd02755685f6

There are a few failing wfShellExec in the exec log bucket:

$ grep -c getConfiguration archive/exec.log-20160916
248

That is from 19:12:01 till 19:59:54 and they all come from terbium for the wikidatawiki.   The failing message being:

Probably exited with signal 25:
/bin/bash '/srv/mediawiki/php-1.28.0-wmf.19/includes/limit.sh' ''\''/usr/bin/php'\'' '\''/srv/mediawiki/multiversion/MWScript.php'\'' '\''maintenance/getConfiguration.php'\'' '\''--wiki'\''  SOMEWIKI_NAME_HERE '\''--settings'\'' '\''wgJobClasses'\'' '\''--format'\'' '\''PHP'\''' 'MW_INCLUDE_STDERR=;MW_CPU_LIMIT=50; MW_CGROUP='\''/sys/fs/cgroup/memory/mediawiki/job'\''; MW_MEM_LIMIT=0; MW_FILE_SIZE_LIMIT=524288; MW_WALL_CLOCK_LIMIT=180; MW_USE_LOG_PIPE=yes'

Or in a human friendly way:

MW_INCLUDE_STDERR=;
MW_CPU_LIMIT=50;
MW_CGROUP='/sys/fs/cgroup/memory/mediawiki/job';
MW_MEM_LIMIT=0;
MW_FILE_SIZE_LIMIT=524288;
MW_WALL_CLOCK_LIMIT=180;
MW_USE_LOG_PIPE=yes
mwscript maintenance/getConfiguration.php --wiki=WIKI_NAME --settings wgJobClasses --format PHP

The "signal 25" is extracted by wfShellExec. Looks like the exit code was 153 or 128 + 25.  From man 7 signal that would be SIGXFSZ:

SIGXFSZ 25,25,31CoreFile size limit exceeded (4.2BSD)

MW_FILE_SIZE_LIMIT=524288 is passed as ulimit -f:

-fthe maximum size of files written by the shell and its children

And 524288 == 512 * 1024 bytes

That value seems to come from $wgMaxShellFileSize.  Default to 102400 in MediaWiki and on Wikimedia config it is at 512 * 1024:

wmf-config/CommonSettings.php:1564:$wgMaxShellFileSize = 512 * 1024;

That has been the case for as long as 2015-10-31 and f85267e35fed0d38bb58b181e3382a63f1796266  that made the value the default (previously it was only applied when /etc/wikimedia-image-scaler file existed.



Anyway.  Gotta:


reproduce the file limit and see whether it is areason.
figure out why it overflow
is that really the root cause?


TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, zeljkofilipin, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T145819: Wikidata at 1.28.0-wmf.19 no more replicate to wikis (replag raise / dispatch stop)

2016-09-16 Thread hashar 
hashar added a comment.
So looks like the root cause is:

SiteConfiguration->getConfig(string, array)
php-1.28.0-wmf.19/includes/SiteConfiguration.php:561) Failed to run getConfiguration.php.

And I have also seen a few jobs spurting:

'This script must be run from the command line'

Looks similar to T111441TASK DETAILhttps://phabricator.wikimedia.org/T145819EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: hasharCc: Lydia_Pintscher, daniel, aude, Addshore, Aklapper, greg, Legoktm, demon, gerritbot, Stashbot, hashar, Lewizho99, Maathavan, D3r1ck01, Liudvikas, Izno, Luke081515, Wikidata-bugs, JanZerebecki, zeljkofilipin, Mbch331, Jay8g___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

Re: [Wikidata-tech] Tags in the edit history

2016-09-16 Thread Cristina Sarasua 
Thanks Katie.

And in the dumped edit history, which is the element in RevisionType [1]
that should contain the tags? I guess it's not the comment, then.

Cristina


[1] Edit history Schema: https://www.mediawiki.org/xml/export-0.8.xsd



On Fri, Sep 16, 2016 at 5:03 AM, Katie Filbert 
wrote:

> On Thu, Sep 15, 2016 at 10:12 PM, Cristina Sarasua <
> csara...@uni-koblenz.de> wrote:
>
>> Hi,
>>
>> I have a question regarding the tags [1] added to the edit history of
>> Wikidata.
>>
>> When I look at the contributions of a user at the wiki [2], I see the
>> comment of the edit (e.g. " (‎Created claim: country (P17): Denmark
>> (Q35), #petscan)") and a special tag that indicates that WiDaR-based
>> software was used to edit (e.g.  (Tag: Widar [1.4]), reCh).
>>
>> However, when I look up the contributions of the same user that I have
>> checked in the Wiki, this time via the API [3], I don't see the "Widar" tag
>> in the comment.
>>
>> Is there a way to identify these special tags (programmatically) in the
>> edit history?
>>
>
> There is ucprop=tags which adds tags, if they exist for an edit, and uctag
> which can be used to filter the edits:
>
> https://www.wikidata.org/w/api.php?action=query=
> usercontribs=tags=aude=OAuth%20CID:%20378
>
> Here, WiDaR is "OAuth CID: 378"
>
> Cheers,
> Katie
>
>
>
>>
>> Cristina
>>
>>
>>
>>
>>
>>
>> [1] https://www.wikidata.org/wiki/Special:Tags
>> [2] https://www.wikidata.org/w/index.php?limit=50=Spec
>> ial%3AContributions=user=User=&
>> tagfilter==2016=-1
>> [3] https://www.wikidata.org/w/api.php?action=query=use
>> rcontribs=user
>>
>> --
>> Cristina Sarasua
>>
>> Institute for Web Science and Technologies (WeST)
>>
>> Universität Koblenz-Landau
>> Universitätsstraße 1
>> 56070 Koblenz
>> Germany
>>
>> e-mail: csara...@uni-koblenz.de
>> phone: +49 261 287 2772
>> fax: +49 261 287 100 2772
>> web site: http://west.uni-koblenz.de
>>
>> ___
>> Wikidata-tech mailing list
>> Wikidata-tech@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>>
>>
>
>
> --
> Katie Filbert
> Wikidata Developer
>
> Wikimedia Germany e.V. | Tempelhofer Ufer 23-24, 10963 Berlin
> Phone (030) 219 158 26-0
>
> http://wikimedia.de
>
> Wikimedia Germany - Society for the Promotion of free knowledge eV Entered
> in the register of Amtsgericht Berlin-Charlottenburg under the number 23
> 855 as recognized as charitable by the Inland Revenue for corporations I
> Berlin, tax number 27/681/51985.
>
> ___
> Wikidata-tech mailing list
> Wikidata-tech@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>
>


-- 
Cristina Sarasua

Institute for Web Science and Technologies (WeST)

Universität Koblenz-Landau
Universitätsstraße 1
56070 Koblenz
Germany

e-mail: csara...@uni-koblenz.de
phone: +49 261 287 2772
fax: +49 261 287 100 2772
web site: http://west.uni-koblenz.de
___
Wikidata-tech mailing list
Wikidata-tech@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-tech

[Wikidata-bugs] [Maniphest] [Claimed] T144923: Add special page to show entity usage in client

2016-09-16 Thread Ladsgroup 
Ladsgroup claimed this task.
TASK DETAILhttps://phabricator.wikimedia.org/T144923EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: Aklapper, Liuxinyu970226, Ricordisamoa, Edgars2007, Ainali, gerritbot, Lydia_Pintscher, thiemowmde, Jan_Dittrich, daniel, Ladsgroup, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T143147: wbentityusage as a list API module

2016-09-16 Thread Ladsgroup 
Ladsgroup added a project: Wikidata-Sprint-2016-08-30.
TASK DETAILhttps://phabricator.wikimedia.org/T143147EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/To: LadsgroupCc: Aklapper, Ricordisamoa, Edgars2007, Ainali, gerritbot, Lydia_Pintscher, thiemowmde, Jan_Dittrich, Ladsgroup, Lewizho99, Maathavan, D3r1ck01, Izno, Wikidata-bugs, aude, Mbch331___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs