Learn more about these different git repos.
Other Git URLs
A colleague in my team (/cc @asamalik) noticed that pushing to the modularity repository wouldn't trigger building the website from sources. We found out that this is due to the server-side post-receive hook on pagure.io throwing a ValueError because the LC_CTYPE environment variable was set to UTF-8 and that it's probably inherited from the client-side environment. I consider the value to be invalid but apparently it is widespread when the client machine runs macOS.
modularity
ValueError
LC_CTYPE
UTF-8
Here's a reproducer:
nils@gibraltar:~/src/modularity/modularity (master)> git co -b throwaway Switched to a new branch 'throwaway' nils@gibraltar:~/src/modularity/modularity (throwaway)> vi README.md nils@gibraltar:~/src/modularity/modularity (throwaway)> git ci -a -m "doot" [throwaway 9c6d35e] doot 1 file changed, 2 insertions(+) nils@gibraltar:~/src/modularity/modularity (throwaway)> git remote get-url pagure ssh://git@pagure.io/forks/nphilipp/modularity.git nils@gibraltar:~/src/modularity/modularity (throwaway)> LC_CTYPE=UTF-8 git push --set-upstream pagure throwaway perl: warning: Setting locale failed. perl: warning: Please check that your locale settings: LANGUAGE = (unset), LC_ALL = (unset), LC_PAPER = "en_GB.UTF-8", LC_MONETARY = "en_GB.UTF-8", LC_NUMERIC = "en_GB.UTF-8", LC_MEASUREMENT = "en_GB.UTF-8", LC_CTYPE = "UTF-8", LC_TIME = "en_GB.UTF-8", LANG = "en_US.UTF-8" are supported and installed on your system. perl: warning: Falling back to the standard locale ("C"). Counting objects: 31, done. Delta compression using up to 8 threads. Compressing objects: 100% (30/30), done. Writing objects: 100% (31/31), 3.80 KiB | 3.80 MiB/s, done. Total 31 (delta 23), reused 0 (delta 0) remote: perl: warning: Setting locale failed. remote: perl: warning: Please check that your locale settings: remote: LANGUAGE = (unset), remote: LC_ALL = (unset), remote: LC_PAPER = "en_GB.UTF-8", remote: LC_MONETARY = "en_GB.UTF-8", remote: LC_NUMERIC = "en_GB.UTF-8", remote: LC_MEASUREMENT = "en_GB.UTF-8", remote: LC_CTYPE = "UTF-8", remote: LC_TIME = "en_GB.UTF-8", remote: LANG = "en_US.UTF-8" remote: are supported and installed on your system. remote: perl: warning: Falling back to the standard locale ("C"). remote: Traceback (most recent call last): remote: File "./hooks/post-receive.fedmsg", line 15, in <module> remote: import pagure # noqa: E402 remote: File "/usr/lib/python2.7/site-packages/pagure/__init__.py", line 95, in <module> remote: import pagure.doc_utils # noqa: E402 remote: File "/usr/lib/python2.7/site-packages/pagure/doc_utils.py", line 13, in <module> remote: import docutils.core remote: File "/usr/lib/python2.7/site-packages/docutils/core.py", line 20, in <module> remote: from docutils import frontend, io, utils, readers, writers remote: File "/usr/lib/python2.7/site-packages/docutils/frontend.py", line 41, in <module> remote: import docutils.utils remote: File "/usr/lib/python2.7/site-packages/docutils/utils/__init__.py", line 20, in <module> remote: import docutils.io remote: File "/usr/lib/python2.7/site-packages/docutils/io.py", line 18, in <module> remote: from docutils.utils.error_reporting import locale_encoding, ErrorString, ErrorOutput remote: File "/usr/lib/python2.7/site-packages/docutils/utils/error_reporting.py", line 46, in <module> remote: locale_encoding = locale.getlocale()[1] or locale.getdefaultlocale()[1] remote: File "/usr/lib64/python2.7/locale.py", line 511, in getdefaultlocale remote: return _parse_localename(localename) remote: File "/usr/lib64/python2.7/locale.py", line 443, in _parse_localename remote: raise ValueError, 'unknown locale: %s' % localename remote: ValueError: unknown locale: UTF-8 remote: Hook ./hooks/post-receive.fedmsg failed with error code 1 To ssh://pagure.io/forks/nphilipp/modularity.git * [new branch] throwaway -> throwaway Branch throwaway set up to track remote branch throwaway from pagure by rebasing. nils@gibraltar:~/src/modularity/modularity (throwaway)>
I think that Pagure should set up a clean environment (in the hooks themselves or elsewhere) before the hooks are run.
Metadata Update from @pingou: - Issue tagged with: bug
Metadata Update from @pingou: - Issue set to the milestone: Coming 3 months
@nphilipp could you check if this still happens in staging? I think the way the hooks have been changed may have fixed this issue.
I can't seem to reproduce the issue in staging or prod. Closing.
Metadata Update from @nphilipp: - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.