This seems like an issue with aspects.py. The test finds out it is not logged in, it tries to log in successfully, but still skips the test as unable to log in
Also this happens sometimes for lgtoken, sometimes for username and sometimes for password, another weird thing
Wed, Feb 26
Weird is this happens only for zh.wikisource, not for enwiki, not for wikidata, commons, testwiki, testwikidata, arwiktionary and not for Beta Cluster.
After some other tests:
zh.wikisource.org API sometimes generates invalid new token (using action=query&meta=tokens). This token gives login response of NeedToken with another invalid token generated. This token gives login response of NeedToken with yet another invalid token generated. And so on...
After a couple of attempts I successfully reproduced it also using zh:ws API sandbox
Tue, Feb 25
It happens only sometimes, which is weird, I'll investigate it further
The loop in line 3148 does seem correct to me
Also, what is the output of echo $LC_CTYPE and echo $LANG? Weird is this happens only for some letters. I can not reproduce it on my machine. If you use Pywikibot packaged with scripts, could you share the output of python pwb.py version?
This seems like an encoding issue
Mon, Feb 24
Does this still occur?
See T241413 for possible issues
This seems to be classic login issue lately. Tests can't login, can't relogin and are complaining they are not logged in.
Fails also for zh.wikisource.org
Waiting for tests to complete
Yes, Beta Wikisource login works again, either through API, or through web interface!
Weird enought this fails only occasionally and not with maxlag timeout, but with regular timeout
Okay, MusciBrainz is an issue with MediaWiki, but also requires small fix on MusicBrainz side.
There are multiple possible solutions. I can think of two at least:
- add code_aliases to family.langs (this would mean many redirected urls in family.langs which seems wrong to me)
- create separate redirect domain list like family.redirect_domains or family.redirect_langs
Sun, Feb 23
Weird enough this happens only in tests, so there is some issue with aspects.py
Okay, I investigated this and it seems code_aliases or interwiki_replacements is shared between wikimedia_family class families. This is bad, because if I add specific code_aliases to a wikimedia_family class family, it is shared between all of them. Therefore specific code_aliases for Wikisource makes non-existing language codes to be redirected to mul even for Wikipedia! (see https://travis-ci.org/dvorapa/pywikibot/jobs/654053005 for more details)
Sat, Feb 22
Now we need to know, why is this happening, because I don't feel like there are so many new files in Commons with this character
We should use action=checktoken for a token validation, but I'm not sure, where to put this check. It needs to check before every write/relogin action I think
$wgInterwikiMagic=false seems to be ignored by API
It seems action=query&prop=siteinfo&siprop=interwikimap automatically considers ab interwiki as Abkhazian language interwiki for acousticbrainz.org/$1 and lb as Luxembourgish for listenbrainz.org/$1
Asked in the MusicBrainz bug tracker, but I feel like this isn't their fault. Is this even configurable in MediaWiki, that ab is not Abkhazian MusicBrainz wiki, but AcousticBrainz website?
I don't understand it either. Could you find out, which file makes this (or is it for random files?) and also tell me, which wiki do you check? (Commons?)
I'm sorry, I don't understand, what your script does and how. There should be no title in commons with that character and if there are links to a page with that character, the freshly called InvalidTitle error should be always checked in scripts.
Fri, Feb 21
So we can close this?
After last patch en:musicbrainz fails with the same issue as en:betawikisource.
Another thing is, that this might indicate API can not handle this problem correctly:
Seems like an Upstream issue, compare:
Is this correct?
See also T243123
Pywikibot tests are failing due to this issue since summer. Sometimes also in production wikis (zh.wikisource.org). See https://travis-ci.org/wikimedia/pywikibot/jobs/560331158 (run on the July 21, 2019)
Thu, Feb 20
Wed, Feb 19
Currently throwing a warning about sw language
Anything left here?
What is missing here?
Is this still an issue?
You can avoid this bug by registering family file in your script directly, not in user-config btw
Okay, I made some detective work to find out, what could be wrong and I got to this traceback:
$ python Python 3.8.1 (default, Jan 22 2020, 06:38:00) [GCC 9.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import pywikibot >>> s=pywikibot.Site() Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/home/pavel/pywikibot/pywikibot/tools/__init__.py", line 1790, in wrapper return obj(*__args, **__kw) File "/home/pavel/pywikibot/pywikibot/__init__.py", line 1242, in Site fam = Family.load(fam) File "/home/pavel/pywikibot/pywikibot/tools/__init__.py", line 1790, in wrapper return obj(*__args, **__kw) File "/home/pavel/pywikibot/pywikibot/family.py", line 1008, in load raise UnknownFamily('Family %s does not exist' % fam) pywikibot.exceptions.UnknownFamily: Family projectgorgon does not exist
This seems clear, deprecation wrapper tries to load family before config is fully processed. There is another minor issue, as deprecation wrapper silently pass this error and therefore the rest of config is never loaded (register_family_file in config does not work)
I'm sorry, but could you post steps to reproduce without docker or unittests? I don't have server to run docker on and also don't want to break my OS, also I still miss any kind of traceback or error message. What do you want to achieve and what is broken?
You register family file from app folder, but it is not in app folder?