- 28 Jul, 2020 1 commit
-
-
Zen Fu authored
This is an ugly workaround to get rid of noise in tails-translations mailing list. The Python version in Debian Stretch has a bug that leaks memory in some situations and will spit out the following error: ------------------------------------------------------------------------------ Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fe488c03048> Traceback (most recent call last): File "/usr/lib/python3.5/weakref.py", line 117, in remove TypeError: 'NoneType' object is not callable Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7fe488c03048> Traceback (most recent call last): File "/usr/lib/python3.5/weakref.py", line 117, in remove TypeError: 'NoneType' object is not callable Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f69c5515ea0> Traceback (most recent call last): File "/usr/lib/python3.5/weakref.py", line 117, in remove TypeError: 'NoneType' object is not callable Exception ignored in: <function WeakValueDictionary.__init__.<locals>.remove at 0x7f69c5515ea0> Traceback (most recent call last): File "/usr/lib/python3.5/weakref.py", line 117, in remove TypeError: 'NoneType' object is not callable ------------------------------------------------------------------------------ As our scripts run frequently, we are getting many e-mails that are actually false positives. The differences from the original file are: ------------------------------------------------------------------------------ --- weakref.py 2020-07-28 22:54:59.837435324 +0000 +++ /usr/lib/python3.5/weakref.py 2020-07-09 13:00:10.000000000 +0000 @@ -106,7 +106,7 @@ self, *args = args if len(args) > 1: raise TypeError('expected at most 1 arguments, got %d' % len(args)) - def remove(wr, selfref=ref(self), _atomic_removal=_remove_dead_weakref): + def remove(wr, selfref=ref(self)): self = selfref() if self is not None: if self._iterating: @@ -114,7 +114,7 @@ else: # Atomic removal is necessary since this function # can be called asynchronously by the GC - _atomic_removal(d, wr.key) + _remove_dead_weakref(d, wr.key) self._remove = remove # A list of keys to be removed self._pending_removals = [] ------------------------------------------------------------------------------ See the following links for more context: https://helpdesk.tetrane.com/hc/en-us/articles/360034629091-I-am-getting-exceptions-from-usr-lib-python3-5-weakref-py-is-it-an-issue- https://bugs.python.org/issue29519 This will have to be removed once the machine is upgraded to a newer Debian version.
-
- 24 Jul, 2020 5 commits
-
-
Zen Fu authored
-
Zen Fu authored
-
Zen Fu authored
Maintaining HTTPS for now, as it's not a regression in this case. We can probably use the role-jenkins-isotester user for this once the SSH key of GitLab has been deployed in isotesters. I'm not sure if yet another key would have to be added that user's config in GitLab. See: https://salsa.debian.org/tails-team/gitlab-migration/-/issues/97
-
Zen Fu authored
- 23 Jul, 2020 5 commits
-
-
Zen Fu authored
-
Zen Fu authored
-
-
Zen Fu authored
We're migrating check-mirrors.git to GitLab, and the repo in git.tails.boum.org will go away. Manual steps done previous to this: - Creation of user role-check-mirrors in GitLab. - Configuration of the SSH key of tails_check_mirrors@misc.lizard in the role-check-mirrors user account in GitLab.
-
- 22 Jul, 2020 3 commits
-
-
Zen Fu authored
Pushes from weblate-gatekeeper should be done as the "role-weblate-gatekeeper" GitLab user, and for that we need to use a specific SSH key when pushing. This commit adds a new "Host" in gitolite's SSH config and changes the remote URL of the gatekeeper repo to use the that new host, thus making use of the correct key to connect to GitLab. See: https://salsa.debian.org/tails-team/gitlab-migration/-/issues/74
-
Zen Fu authored
We'll use a new user with new SSH keys to configure pushing of changes made by the Translation Platform into GitLab's tails.git. This commit puts the newly generated keys in place. See: https://salsa.debian.org/tails-team/gitlab-migration/-/issues/74
-
Zen Fu authored
Due to a wrong understanding of how the Translation Platform integration scripts work, we have previously configured force-pushes from the integration repo into the new gatekeeper repository. Actually, such forcing shouldn't be necessary because: - Gatekeeper should always be a subset of GitLab, and - Integration should fail early when fast-forwarding is not possible. This commit only reverts the pushing from integration to gatekeeper to be a normal push instead of a force-push.
-
- 18 Jul, 2020 1 commit
-
-
intrigeri authored
-
- 12 Jul, 2020 1 commit
-
-
intrigeri authored
We changed the Jenkins configuration to pull from GitLab while the mirroring to Gitolite was not working: tails/jenkins-jobs@4db52b22 But we did not adjust this post-receive hook accordingly, so the "pushing to Git triggers a Jenkins build" behavior is broken. Let's repair this, until we make up our mind (tails/sysadmin#17715) wrt. whether we should keep pointing Jenkins to GitLab's tails/tails, or use the local mirror we have on puppet-git.lizard.
-
- 10 Jul, 2020 2 commits
- 09 Jul, 2020 1 commit
-
-
intrigeri authored
-
- 08 Jul, 2020 1 commit
-
-
intrigeri authored
-
- 03 Jul, 2020 7 commits
-
-
Zen Fu authored
-
Zen Fu authored
-
Zen Fu authored
-
intrigeri authored
Without disabling CSRF (complicated, will probably become impossible at some point), we did not manage to have jenkins-job-builder use the API with current Jenkins LTS. Using the standard security setup (https://wiki.jenkins.io/display/JENKINS/Standard+Security+Setup), an actual user, and its API token, repairs communication with the API. refs tails/sysadmin#16955
-
intrigeri authored
refs: tails/sysadmin#16955
-
intrigeri authored
Closes tails/tails#17755, tails/puppet-tails!7
-
- 27 Jun, 2020 3 commits
-
-
intrigeri authored
Now that we're running check-mirrors.rb 4 times more often, there's greater chances that 2 of them end up running at the same time. Let's avoid having to reason about how check-mirrors.rb manages shared resources such as its failures.json state file. refs: tails/tails#17755
-
intrigeri authored
refs: tails/tails#17755
-
intrigeri authored
refs: tails/tails#17755
-
- 26 Jun, 2020 1 commit
-
-
intrigeri authored
-
- 23 Jun, 2020 1 commit
-
-
sajolida authored
-
- 15 Jun, 2020 8 commits
-
-
Zen Fu authored
-
Zen Fu authored
-
Zen Fu authored
-
Zen Fu authored
See: https://salsa.debian.org/tails-team/gitlab-migration/-/issues/55 I'll change manually in repo during deploy.
-
Zen Fu authored
See: https://salsa.debian.org/tails-team/gitlab-migration/-/issues/74 I'll modify manually in the server.
-
Zen Fu authored
-
Zen Fu authored
For some reason, our script is not detecting some dependency constraints correctly, so i'm pinning this one manually. From: https://github.com/django-compressor/django-compressor/blob/2.4/setup.py#L148
-
Zen Fu authored
It is now installed with pip. I'll remove the package manually from the server after deploy.
-