#90 Building the docs fails?
Closed 6 years ago Opened 6 years ago by ralph.

I tried cutting a waiverdb-0.4.0 release only to find that the docs failed to build for me.

In particular, make -C docs html text failed.


I've temporarily disabled building the tests in the spec file for Fedora: https://src.fedoraproject.org/rpms/waiverdb/c/362128ad4b4b2948ebb7c1b34685de52d9c26e1e

Once we sort this out, we should re-enable building those.

Interesting. I can't reproduce it. Besides, our last jenkins job is passed. What error did you see? Any traceback?

I enabled it with this patch and used this fedpkg local and it worked.

`git diff
diff --git a/waiverdb.spec b/waiverdb.spec
index 0ad9524..ccff196 100644
--- a/waiverdb.spec
+++ b/waiverdb.spec
@@ -115,9 +115,9 @@ sed -i 's/.stg.fedoraproject.org/.fedoraproject.org/g' conf/client.conf.examp
%build
%py2_build
# https://pagure.io/waiverdb/issue/90
-#%%if 0%%{?fedora}
-#make -C docs html text
-#%%endif
+%if 0%{?fedora}
+make -C docs html text
+%endif

%install
%py2_install
@@ -146,9 +146,9 @@ py.test tests/
%doc README.md conf
# Docs temporarilly disabled
# https://pagure.io/waiverdb/issue/90
-#%%if 0%%{?fedora}
-#%%doc docs/_build/html docs/_build/text
-#%%endif
+%if 0%{?fedora}
+%doc docs/_build/html docs/_build/text
+%endif
%{python2_sitelib}/%{name}/init.py
%{python2_sitelib}/%{name}
.egg-info
`

fedpkg mockbuildfailed with this error:

Warning, treated as error:
WARNING: GET https://pagure.io/api/0/waiverdb/issue/73 failed with error: HTTPSConnectionPool(host='pagure.io', port=443): Max retries exceeded with url: /api/0/waiverdb/issue/73 (Caused by NewConnectionError('<requests.packages.urllib3.connection.VerifiedHTTPSConnection object at 0x7fec35f1c310>: Failed to establish a new connection: [Errno -2] Name or service not known',))

It seems like there might be a network problem on pagure side, though I can visit https://pagure.io/api/0/waiverdb/issue/73 in my web browser.

I did fix this in the copy of waiverdb.spec which lives in our source tree here. @mjia you even reviewed this commit not that long ago :-P

https://pagure.io/waiverdb/c/5a76bd0970993ef50ef5051295693ac1c4f2f813?branch=master

We probably need a little helper script in Fedora dist-git to keep the .spec in sync with the one we are testing/maintaining here. Like this one:

http://pkgs.devel.redhat.com/cgit/rpms/beaker/tree/update-from-upstream.sh?h=eng-rhel-6

Also looks like @ralph split out -common and -cli subpackages in dist-git (I was wondering about that... sucks that we need -common, I wonder if we shoudl just divorce the cli from the service entirely) so we will want to bring those changes back in here too.

Aha, I did not notice it. Yeah, we have a helper script like this in Greenwave and I'll copy it over to waiverdb. I'm not quite sure why we need to have -common since -cli is not really dependent on -common.

Ah, we can maybe figure out another way to split it up. I figured something needed to own waiverdb/__init__.py.

Tomorrow, I'll try to refactor my patches to the spec file in Fedora back into the waiverdb upstream repo here in a PR so we can sort it out.

Yeah @mjia and I were discussing it. Personally I think the CLI should just have an independent Python package, let's call it waiverdbcli. We can probably have them live together as they do now, with the same setup.py, and just split them apart in the RPM.

We have a -common subpackage in Beaker and I dislike that approach, it caused us a lot of headaches over the years. Better to keep the CLI independent of the server as much as possible, I think.

Better to keep the CLI independent of the server as much as possible, I think.

:+1:

See also https://pagure.io/waiverdb/pull-request/93 for trying to get the specfiles back in line.

Hm, is this still an issue? I'll try to build them again and confirm or deny.

Metadata Update from @ralph:
- Issue assigned to ralph

6 years ago

Ok, here's a failed scratch build, and the logs. It fails trying to talk to pagure.io during the build process. This must be that new-fangled sphinxcontrib.issuetracker.

Yeah so the commit I mentioned above was supposed to make that warning non-fatal to the RPM build. The Fedora .spec must still not be fully in sync with the .spec we have here...

Yup. That should do it.

On it. It's this: https://github.com/ignatenkobrain/sphinxcontrib-issuetracker/pull/13

I will file a PR to fix it in the Fedora package since Igor has not merged the PR upstream yet for some reason.

Full traceback:

+ cat /tmp/sphinx-err-fmPTrt.log
# Sphinx version: 1.6.5
# Python version: 2.7.14 (CPython)
# Docutils version: 0.14 
# Jinja2 version: 2.10
# Last messages:
#   not yet created
#   loading intersphinx inventory from python-intersphinx.inv...
#   building [mo]: targets for 0 po files that are out of date
#   building [html]: targets for 5 source files that are out of date
#   updating environment:
#   5 added, 0 changed, 0 removed
#   reading sources... [ 20%] api
#   reading sources... [ 40%] developer-guide
#   reading sources... [ 60%] index
#   reading sources... [ 80%] release-notes
# Loaded extensions:
#   sphinxcontrib.autohttp.flask (unknown version) from /usr/lib/python2.7/site-packages/sphinxcontrib/autohttp/flask.pyc
#   sphinxcontrib.issuetracker (unknown version) from /usr/lib/python2.7/site-packages/sphinxcontrib/issuetracker/__init__.pyc
#   sphinx.ext.viewcode (1.6.5) from /usr/lib/python2.7/site-packages/sphinx/ext/viewcode.pyc
#   sphinx.ext.napoleon (1.6.5) from /usr/lib/python2.7/site-packages/sphinx/ext/napoleon/__init__.pyc
#   sphinx.ext.autodoc (1.6.5) from /usr/lib/python2.7/site-packages/sphinx/ext/autodoc.pyc
#   sphinx.ext.intersphinx (1.6.5) from /usr/lib/python2.7/site-packages/sphinx/ext/intersphinx.pyc
#   sphinx.ext.doctest (1.6.5) from /usr/lib/python2.7/site-packages/sphinx/ext/doctest.pyc
#   alabaster (0.7.9) from /usr/lib/python2.7/site-packages/alabaster/__init__.pyc
#   sphinxcontrib.httpdomain (unknown version) from /usr/lib/python2.7/site-packages/sphinxcontrib/httpdomain.pyc
Traceback (most recent call last):
  File "/usr/lib/python2.7/site-packages/sphinx/cmdline.py", line 306, in main
    app.build(opts.force_all, filenames)
  File "/usr/lib/python2.7/site-packages/sphinx/application.py", line 339, in build
    self.builder.build_update()
  File "/usr/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 331, in build_update
    'out of date' % len(to_build))
  File "/usr/lib/python2.7/site-packages/sphinx/builders/__init__.py", line 344, in build
    updated_docnames = set(self.env.update(self.config, self.srcdir, self.doctreedir))
  File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", line 584, in update
    self._read_serial(docnames, self.app)
  File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", line 603, in _read_serial
    self.read_doc(docname, app)
  File "/usr/lib/python2.7/site-packages/sphinx/environment/__init__.py", line 731, in read_doc
    domain.process_doc(self, docname, doctree)
  File "/usr/lib/python2.7/site-packages/sphinx/domains/std.py", line 576, in process_doc
    self.note_citation_refs(env, docname, document)
  File "/usr/lib/python2.7/site-packages/sphinx/domains/std.py", line 592, in note_citation_refs
    if node['refdomain'] == 'std' and node['reftype'] == 'citation':
  File "/usr/lib/python2.7/site-packages/docutils/nodes.py", line 567, in __getitem__
    return self.attributes[key]
KeyError: 'refdomain'

Metadata Update from @ralph:
- Assignee reset

6 years ago

Metadata Update from @dcallagh:
- Issue assigned to ralph

6 years ago

Hmm. Pagure says I just assigned this issue to @ralph but I didn't. Maybe because I wrote a comment at the same time you were changing the assignee @ralph ...?

Metadata Update from @dcallagh:
- Issue assigned to dcallagh (was: ralph)

6 years ago

FYI, I submitted a buildroot override which should get this building again.

Metadata Update from @mjia:
- Issue status updated to: Closed (was: Open)

6 years ago

Login to comment on this ticket.

Metadata