Closed bertsky closed 2 years ago
CI failure: the same idiotic reason as in the other PRs. Anyone has a solution?
Building with Python 3.7 no longer works for me after I merged this PR. It fails for the
headless-tf1
parts.
Then please share the error log so we can resolve this quickly.
I also tried Python 3.9 (the default for Debian stable) which failed similarly.
Yeah sure, but that's true for master, too. (I am not claiming I can solve all problems at once.)
CI failure:
. /usr/local/sub-venv/headless-torch14/bin/activate && sem --will-cite --fg --id ocrd_all_pip/usr/local/sub-venv/headless-torch14 pip3 install --upgrade pip setuptools
Exception:
Traceback (most recent call last):
File "/usr/local/sub-venv/headless-torch14/lib/python3.6/site-packages/pip/basecommand.py", line 215, in main
status = self.run(options, args)
File "/usr/local/sub-venv/headless-torch14/lib/python3.6/site-packages/pip/commands/install.py", line 290, in run
with self._build_session(options) as session:
File "/usr/local/sub-venv/headless-torch14/lib/python3.6/site-packages/pip/basecommand.py", line 69, in _build_session
if options.cache_dir else None
File "/usr/lib/python3.6/posixpath.py", line 80, in join
a = os.fspath(a)
TypeError: expected str, bytes or os.PathLike object, not int
I remember seeing this before, and solving be replacing/removing the pip cache dir.
Then please share the error log so we can resolve this quickly.
See https://github.com/stweil/ocrd_all/actions.
Before merging this pull request, Python 3.6 and Python 3.7 work fine while Python 3.8 fails as expected (https://github.com/stweil/ocrd_all/actions/runs/1937666710).
After merging this pull request, Python 3.6 and Python 3.8 work, but Python 3.7 fails (https://github.com/stweil/ocrd_all/actions/runs/1937673668).
After merging this pull request, Python 3.6 and Python 3.8 work, but Python 3.7 fails (https://github.com/stweil/ocrd_all/actions/runs/1937673668).
Thanks! I updated the workaround to only activate in the case of Python 3.8. (AFAICS, on 3.7 this is not necessary, and we simply do not newer versions anyway.)
I remember seeing this before, and solving be replacing/removing the pip cache dir.
Which is strange, because you would expect the CI container to start without a cache, and without -j
there should be no outside interference/race against the cache...
Current CI failure is the 1h timeout again. :disappointed:
@bertsky, I think we can address the unhandled target architectures later and apply the pull request.
Maybe you can change the code which checks the Python version and introduce a new macro PYTHON_VERSION
which will be needed for other rules, too: https://github.com/stweil/ocrd_all/commit/663544450eb9d51e96aea8619dcb94149637e7e7
@stweil,
I think we can address the unhandled target architectures later and apply the pull request.
Definitely. When and if...
Maybe you can change the code which checks the Python version and introduce a new macro
PYTHON_VERSION
which will be needed for other rules, too: stweil@6635444
There's a recipe here already which detects the major version. IIUC you want to expose that as a make variable for other rules as well. How is that related to this PR?
CI: 033b5dd does the trick for now. We should revisit the problems related to use of make -j
later, but for now the time is just enough for the 1h+1m limit. (We can still disable the lengthy docker image save
and artifact uploading later, if we exceed the limit but have not tackled the parallel build issues yet.)
Thus, ready for merging.
Now runs into the CircleCI timeout again. I'll disable saving artifacts.
Depends on https://github.com/OCR-D/ocrd_anybaseocr/pull/89 (which in turn depends on https://github.com/OCR-D/ocropy/pull/2).