The other images affected were File:Paar handschoenen, objectnr KA 15683.12.tif and Schild,_objectnr_KA_15728.tif. All have now passed tests and have been manually updated in the database to reflect the fact that they are not corrupt. I have also reverted TSB's edits relating to these images and notified the uploader that it has been fixed.
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 8 2020
Updating the server's version of my PIL flavour appears to have resolved some of these issues. Still investigating more.
2020-02-08 07:54:06,423 __main__ : INFO File:Yackety yack (1901) - DPLA - 30e4078df08e452cbcded5fd72443251 (page 246).jpg :Not corrupt. Stored 2020-02-08 07:54:06,426 __main__ : INFO File:Regina Doherty 2015.jpg 2020-02-08 07:54:06,666 Image : WARNING KeyError1 has occurred Traceback (most recent call last): File "/home/ccc/Commons-image-corruption-detector/Image.py", line 29, in getRevision revision = file_page.get_file_history()[pywikibot.Timestamp.fromtimestampformat(self.log_timestamp)] KeyError: Timestamp(2020, 2, 8, 7, 44, 20)
Feb 7 2020
Just happened again at random.
2020-02-08 01:32:01,153 __main__ : INFO File:AIIPlogo3d.png Traceback (most recent call last): File "rcworker.py", line 216, in <module> main() File "rcworker.py", line 209, in main run_worker() File "rcworker.py", line 105, in run_worker revision = change.getRevision(file_page) File "/home/ccc/Commons-image-corruption-detector/Image.py", line 24, in getRevision revision = file_page.get_file_history()[pywikibot.Timestamp.fromtimestampformat(self.log_timestamp)] File "/usr/local/lib/python3.8/site-packages/pywikibot/__init__.py", line 210, in fromtimestampformat return cls.strptime(ts, cls.mediawikiTSFormat) File "/usr/local/lib/python3.8/_strptime.py", line 568, in _strptime_datetime tt, fraction, gmtoff_fraction = _strptime(data_string, format) File "/usr/local/lib/python3.8/_strptime.py", line 349, in _strptime raise ValueError("time data %r does not match format %r" % ValueError: time data '2020-01-17T13:54:19Z' does not match format '%Y%m%d%H%M%S'
Cannot reproduce locally nor on server side.
Initial tests do not appear able to reproduce this locally.
Logging ini based off of this stack overflow post with influence from RealPython.com.
Feb 6 2020
Now works. :)
Traceback (most recent call last): File "rcworker.py", line 188, in <module> main() File "rcworker.py", line 183, in main run_worker() File "rcworker.py", line 61, in run_worker change = pickle.loads(pickle) # Need to unpickle and build object once more - T99 AttributeError: 'bytes' object has no attribute 'loads' CRITICAL: Exiting due to uncaught exception <class 'AttributeError'>
I have filed a task/ticket on Wikimedia's Phabricator install regarding this. Cannot seem to screen it out and have asked for advice there.
Collecting sseclient Downloading sseclient-0.0.24.tar.gz (6.7 kB) Requirement already satisfied: requests>=2.9 in /usr/local/lib/python3.8/site-packages (from sseclient) (2.22.0) Requirement already satisfied: six in /usr/local/lib/python3.8/site-packages (from sseclient) (1.14.0) Requirement already satisfied: chardet<3.1.0,>=3.0.2 in /usr/local/lib/python3.8/site-packages (from requests>=2.9->sseclient) (3.0.4) Requirement already satisfied: certifi>=2017.4.17 in /usr/local/lib/python3.8/site-packages (from requests>=2.9->sseclient) (2019.11.28) Requirement already satisfied: idna<2.9,>=2.5 in /usr/local/lib/python3.8/site-packages (from requests>=2.9->sseclient) (2.8) Requirement already satisfied: urllib3!=1.25.0,!=1.25.1,<1.26,>=1.21.1 in /usr/local/lib/python3.8/site-packages (from requests>=2.9->sseclient) (1.25.7) Installing collected packages: sseclient Running setup.py install for sseclient ... done Successfully installed sseclient-0.0.24
Feb 5 2020
Feb 4 2020
Resolved.
Looks like notification tests are done for now and working as expected. :)
Set put_throttle to 3 (from 10) inside user-config.py, which is not repo tracked. This appears to have sped it up appropriately. maxthrottle and maxlag were not changed and have remained their default values.
Wrong ticket. Oops
Confirmed with this edit. Closing.
Once verified notifications working, will close.
Resolved. Better solution should be implemented though that doesn't require .value calls everywhere.
Still more work needed. Need to print out the value vs the literal enum name. Will need to look further when I have more time.
Works now. Thanks @AntiCompositeNumber ! (Also thanks for adding the backwards compatibility.)
Template now takes an ISO date as |date=, or as the existing |year= |month= |day=.
It would be best to use https://commons.wikimedia.org/wiki/Template:ISOdate for this as it handles localization automagically.
Feb 3 2020
Aaannnd account created :) @AntiCompositeNumber. Re-assigned.
Assessing as high priority as at current this is delaying testing. I have asked in two IRC channels if anyone has experience with internationalized templates to have a look.