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

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

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

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

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

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

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

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,

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

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,

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

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,

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

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

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

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:

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

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

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

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,

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

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

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

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,

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

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,

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

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

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

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

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

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

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

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

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

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:

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

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,

[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

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

[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

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

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

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

[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

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

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

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

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

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

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

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

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

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:

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

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,

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

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

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

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,

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

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,

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

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.

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

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

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

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,

[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

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

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

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 >

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

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

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

(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

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

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

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

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

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

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

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

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:

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

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,

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

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,

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

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

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

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

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

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:

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

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,

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

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

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

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

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

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

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

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

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

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

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

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

[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)

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

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

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,

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

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,

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

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,

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

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

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

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

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

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

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

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:

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

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:

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

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

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

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,

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

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,

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

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

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

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

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

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,

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

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

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

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

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

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

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

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,

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

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:

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

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,

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

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'

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

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

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

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

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

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

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

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:

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

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

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

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

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

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,

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

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

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

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

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

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,

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

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,

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

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,

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

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

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

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]

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

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

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

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

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

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

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

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

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

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

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

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,

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

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,