nijel
commented
5 years ago I can not reproduce this and it's also working fine in our CI tests. What's your setting for timezone?
Closed rwrx closed 5 years ago
nijel
commented
5 years ago I can not reproduce this and it's also working fine in our CI tests. What's your setting for timezone?
rwrx
commented
5 years ago Thank you. It is weird, now it is working without any problems. I didn't do anything.
sbidoul
commented
5 years ago I'm hitting the same issue. Could it be related to Sentry?
sbidoul
commented
5 years ago I my case WEBLATE_TIME_ZONE is not set in the docker-compose environment.
nijel
commented
5 years ago I'm running this with Sentry as well and I observe no such issues. Any customization of the configuration?
paulpach
commented
5 years ago I tried both without setting WEBLATE_TIME_ZONE and by setting WEBLATE_TIME_ZONE to America/Chicago and I get the same error.
I also noticed dateutil is version 2.6.1 in that docker image, which is ancient. perhaps we can upgrade to 2.7.5?
paulpach
commented
5 years ago I made no customization at all to the docker image. Here are the environment variables passed to it:
WEBLATE_DEBUG=0
WEBLATE_SERVICE_HOST=10.35.255.119
WEBLATE_LOGLEVEL=DEBUG
WEBLATE_EMAIL_PORT=587
WEBLATE_ADMIN_EMAIL=*****
WEBLATE_TIME_ZONE=America/Chicago
WEBLATE_PORT=tcp://10.35.255.119:80
WEBLATE_PORT_80_TCP_PORT=80
WEBLATE_PORT_80_TCP_ADDR=10.35.255.119
WEBLATE_REGISTRATION_OPEN=1
WEBLATE_EMAIL_HOST=smtp.sendgrid.net
WEBLATE_ALLOWED_HOSTS=translate.blockstory.net,*
WEBLATE_PORT_80_TCP_PROTO=tcp
WEBLATE_SERVICE_PORT=80
WEBLATE_EMAIL_USER=*****
WEBLATE_ADMIN_PASSWORD=*****
WEBLATE_PORT_80_TCP=tcp://10.35.255.119:80
WEBLATE_DEFAULT_FROM_EMAIL=weblate@blockstory.net
WEBLATE_ADMIN_NAME=*****
WEBLATE_SERVER_EMAIL=weblate@blockstory.net
WEBLATE_SITE_TITLE=Weblate
WEBLATE_EMAIL_PASSWORD=*****you can reproduce the issue by clicking on this page: http://translate.blockstory.net/projects/cubica/item/
I can turn on DEBUG if that would help
paulpach
commented
5 years ago Notice in the log he posted there are 2 unrelated errors.
The first one is https://github.com/WeblateOrg/docker/issues/102
which can be resolved by deleting /app/data/celery/beat-schedule*
The second one is the time zone issue
paulpach
commented
5 years ago It started working on it's own.
nijel
commented
5 years ago I was thinking about updating dateutil, but I first wanted to confirm it's the issue. But the problem is that I can't reproduce it and it seems to be fixing without any action in most cases, what is really weird.
Anyway I've updated dateutil in https://github.com/WeblateOrg/docker/commit/2cddbdaaca8a6ae50eba2bf89614c67b099019b7
nijel
commented
5 years ago I've just pushed 3.3-2 containing this change, it would be great if somebody still experiencing this issue would test that.
sbidoul
commented
5 years ago @nijel the issue seems to be resolved with the latest docker image. Thanks!
nijel
commented
5 years ago Great, closing the issue as fixed.
msheiny
commented
5 years ago I'm still experiencing this issue using on image 3.3-4.
This was encountered while upgrading an instance (in steps) from 2.20 --> 3.3-4 . It occurred during the transition when I bumped to 3.2.2-5. I figured from there I saw this issue so I thought bumping to 3.3-4 would fix. Unfortunately still same error here. I'm running the docker-compose config with the 3.3-4 docker image backing it.
nijel
commented
5 years ago @msheiny what is the actual error message you get? What is your setting for WEBLATE_TIME_ZONE?
msheiny
commented
5 years ago Hi @nijel - WEBLATE_TIME_ZONE is set to "UTC" as an environment variable (running from docker-compose file).
Here's the traceback:
Some other items pulled from the error (I stripped a lot out, let me know if you want additional debug information from me):
nijel
commented
5 years ago Thanks, I think this has something to do with parsing vcs commit logs. Are you using git or something different? In case it's git, can you please provide me timestamps shown in git log --format=fuller --date=rfc -n1 in the repository for this project?
msheiny
commented
5 years ago @nijel - I am using git! Hrmm just for some context in this scenario I may have had to do some crazy rsync'ing to move some of the /app/data/ directories from my prod server to a staging server. The hostnames changed in this scenario.
Here's the output from the log you requested:
commit c2e8879731271068bc0c995a6c60380cf4393d76
Author: robbpa <robbpaun@gmail.com>
AuthorDate: Wed, 16 Jan 2019 01:49:11 +0000
Commit: Weblate <weblate@freedom.press>
CommitDate: Thu, 17 Jan 2019 02:25:19 +0000
Translated using Weblate (Romanian)
Currently translated at 100.0% (247 of 247 strings)
Translation: SecureDrop/SecureDrop
Translate-URL: https://weblate-sandbox.securedrop.org/projects/securedrop/securedrop/ro/I noticed a few commits down though I have commits pointing to the old server:
commit 3f0cf3f55af25cc93fc31374c6a5c7f29be95050
Author: Ettore Atalan <atalanttore@googlemail.com>
AuthorDate: Mon, 10 Dec 2018 17:37:26 +0000
Commit: Weblate <weblate@freedom.press>
CommitDate: Fri, 14 Dec 2018 07:44:49 +0000
Translated using Weblate (German)
Currently translated at 100.0% (247 of 247 strings)
Translation: SecureDrop/SecureDrop
Translate-URL: https://weblate.securedrop.org/projects/securedrop/securedrop/de/Thanks, however that is apparently not a problem, these parse just fine.
nijel
commented
5 years ago Thank you for your report, the issue you have reported has just been fixed. The problem is that the revision information is cached and thus the cache contains object from older dateutil which is not compatible with current one. I've fixed that by parsing the entries when loading from cache rather than before. The cache keys have been changed anyway in 2fbbc48efc5452fe21dbace3745406d3c8850510.
msheiny
commented
5 years ago Hey @nijel thanks so much for addressing a fix here and for the rapid response. :heart:
Do you have any recommendations for how to work-around this until 3.4 is released ? Can I clear this cache on my instance?
nijel
commented
5 years ago Yes, clearing the cache will help. The 3.4 should be out tomorrow though ;-).
msheiny
commented
5 years ago Greeeeeeat! Dumb question though .... how do I clear the cache for future reference? is that a management command ?
nijel
commented
5 years ago No, that one deletes translation memory. There is no command for clearing the cache. It is not existing for good reason - it can do harm.
Before continuing ensure nobody is actively using Weblate. Then wait until there are no unprocessed entries in the Celery queue (because that one will be deleted as well). You can check that on /api/metrics/ - watch for index_updates and celery_queue to be zero.
Then you can do it in the management shell (on docker you can execute that using docker-compose exec weblate weblate shell):
from django.core.cache import cache
cache.clear()
Hello, I have an installation of Weblate in Docker. Today I decided to upgrade from Weblate 3.2.2 to 3.3 with steps described here: https://docs.weblate.org/en/latest/admin/deployments.html#upgrading-docker-container . But when I have opened it in web browser and clicked on translation project it shows me an Internal Server Error message. In the Docker I am getting this log (from the beginning of starting of Weblate docker image):
I am not sure what could be wrong, or what should I do to fix this, previously when I updgraded Weblate docker image it just worked.