There definitively should be a parser function for this, but perhaps we have to investigate more about its name

Arch Linux: No issue with installation

Good point

Nice, this is what I looked for last 12 months at least :D

I know I might be weird, but I can not see any easy option to find merged patches to a project, which is a good way (for example) to look for regressions, comment merged patchsets (as a good way to communicate about regressions), revert merged patches, etc. The new behavior makes the work with Gerrit quite disturbing and it seems as a bug as some other Gerrit instances I used last time does support project dashboards.

Or just navigate visitors to the MW.org docs from there

Can we with Gerrit 3.2 somehow add some project description, where we could mention this? The same with Phabricator rPWBC project?

Asking ws:it API for namespaces gives broken list when maxlag condition occurs. No maxlag/timeout error, no empty list like in other cases.

In T242083#5954453, @Xqt wrote:

if maxlag Timeout occurs the tests are skipped as expected (see wp.de and wp.en) but it seems there is not maxlag for ws.it. The NamespacesDict is insufficient instead:

Validate page_from_repository on wikipedia:de ... Sleeping for 5.0 seconds, 2020-03-09 16:11:17
Sleeping for 5.0 seconds, 2020-03-09 16:11:22
Sleeping for 5.0 seconds, 2020-03-09 16:11:28
Sleeping for 5.0 seconds, 2020-03-09 16:11:33
Sleeping for 6.2 seconds, 2020-03-09 16:11:38
skipped 'Maximum retries attempted due to maxlag without success.'
 26.987s test_page_from_repository_en_wp (tests.site_tests.TestCategoryFromWikibase)
Validate page_from_repository on wikipedia:en ... Sleeping for 5.0 seconds, 2020-03-09 16:11:44
Sleeping for 5.0 seconds, 2020-03-09 16:11:49
Sleeping for 5.0 seconds, 2020-03-09 16:11:54
Sleeping for 5.0 seconds, 2020-03-09 16:12:00
Sleeping for 7.1 seconds, 2020-03-09 16:12:05
skipped 'Maximum retries attempted due to maxlag without success.'
 27.878s test_page_from_repository_it_ws (tests.site_tests.TestCategoryFromWikibase)
Validate page_from_repository on wikisource:it ... ERROR

This is a new behaviour of api fault ihmo.

Well this is not a thing to debate, there must be some bulletproof statistics. Anyway from my experience, on Czech Wikipedia there is a surprisingly big number of IE users even today.

Browser support?

Ok

code: shn

Last patch works finally. Travis is now forced to uninstall and then reinstall pytest, which resolves all version conflicts.

And now 4.1.0 is conflicting. But pytest should not be installed at all.

CHANGELOG of pytest-cov says they dropped support for py < 3.5, but they mean py3 < 3.5. Arghhhhhhh. Fixed in quick patch, should be ok now

Many thanks!

Well, the original reported issue was for old UI. Aklapper only added the issue occurs also with the new UI

@hashar?

Yeah, it's definitely a Regression as this never hapenned before

I continue to hope that someday, the Linter tracking will actually apply Wikipedia categories, so that we can work with them in the usual way.
One note from a gnome to a developer: "new uses that cause rendering failures will be obvious right away" is not a valid supposition.

Seems resolved now.

I created revert (https://gerrit.wikimedia.org/r/#/c/pywikibot/core/+/604926/), but it can't be merged possibly due to T252310

StackOverflow suggests this:

$ git tag -a 3.0.20200707
$ python3 setup.py sdist
... possibly cleanup or clone a clean repository
$ git reset 3.0.20200609
$ git add .
$ git commit -m "3.0.20200609"
$ git review stable

It should be much more simple like:

$ git tag -a 3.0.20200707
$ python3 setup.py sdist
... possibly cleanup or clone a clean repository
$ git review stable
... pushes master into stable directly

But I feel like this would require to squash all commits since the last version into one commit like described in https://www.mediawiki.org/wiki/Gerrit/Tutorial#Squash_several_commits_into_one_single_commit_via_rebase

With git it should work like this:

In standard git environemnt this would mean just to merge master branch into stable branch after every release, but I'm not familiat how this works with Gerrit (@Urbanecm ?)

After 3.0.2020070x we will no longer need to update python2.

Occured again. Possibly have something to do with git tags, because today were two tags changed and one added.

Oh, should I close this as a duplicate?

Happenned also in Travis wowwiki test

Ecoreality seems to work fine lately

Started to fail cca 4 hours ago, tests passed before. Fails currently only on testwiki and enwpbeta. The following two tests are failing (both should be extremely easy to understand):

Tested 2.7.18 in https://travis-ci.org/github/dvorapa/pywikibot/builds/697066525, everything seems fine

Let's try the API team about the successfull/duplicate messages not retrieved when expected

@bd808 Google requires to pay for using his Maps externally (i.e. in Toolforge tools). But it provides a free access for foundations, who ask for that. Could we somehow on behalf of WMF ask Google (through their provided contact form for these cases) for this access?

Anyway after this announcement reaches Pywikibot mailing list, I'll also publish Tech news, again with the link to the e-mail announcement.

Yes, to my request (I don't know how to work with mailing lists) :)

(I feel like this is not only an add action. Users can ping people, so they know about the conversation (ping action), users can navigate people, so they know who is responsible (navigate action), users can just reply to more people in one comment (reply action)...)

Any additional info from him/her would be much appreciated

@Xqt?

Then I would say this is classic Commons rate-limit issue with large files. Not sure what to do with it.

If the script sends at least one request to Wikidata, then this is caused by Wikidata lag (last week no bot was able to edit Wikidata with correct bot settings).

Yeah, an old issue, you can find more MW 1.19 issues in MW 1.19 tests. Also there is an issue with editmywatchlist right and gsrsearch (also shown in Fandom wiki tests)

Cool!

In T111853#6196291, @Ladsgroup wrote:

In T111853#6196240, @Dvorapa wrote:

Could we remove be-x-old from langlist? Can it break something?

I tried it (then generated the interwiki dump). It removed all interwiki links of be-x-old, meaning [[:be-x-old:foo]] would stop working. I rather try it in another time (gradual improvements).

Cool!

Yeah, numerical work the same, just tested. Okay, that means only syntaxhighlight needs to have exception

Could we remove be-x-old from langlist? Can it break something?

And numerical (unicode, hex-unicode)?

@matej_suchanek Could you try a different character and post results? Ampersand might be an exception on both sides (both PWB and MW)

Yeah, that's what I talked about. Proper solution would be db rename, easy solution would be to add an exception to that dbname -> iw code process

In T111853#6196113, @Ladsgroup wrote:

It shouldn't have anything with the db name (we can't rename db anyway, it's not impossible but you need to stop everything for a significant time to be able to do that given the complexity of our infra). let me see what can be done to fix the be-tarask (to fix this whak-a-mole)