|
Bugzilla – Full Text Bug Listing |
| Summary: | python-wxPython fails to build with doxygen 1.9.7 | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Ana Guerrero <ana.guerrero> |
| Component: | Python | Assignee: | Petr Gajdos <pgajdos> |
| Status: | RESOLVED FIXED | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | bwiedemann, daniel.garcia, foss, guillaume.gardet, pgajdos, stefan.bruens, toddrme2178 |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Attachments: |
build log
doc diff |
||
JFYI, in devel:tools/doxygen, there is even newer version, 1.9.8 Here locally, the difference made %{rebuild_sip}: the package failed when enabled.
I can assist next week (doxygen maintainer here).
https://build.opensuse.org/public/build/openSUSE:Factory/standard/x86_64/python-wxPython:python311/_log says it was last built 2023-08-13 - so where exactly was the failed build? Plus I still fail to see how doxygen is involved there, when it is not installed. It could only be through build results of other packages that got used by wxpython, which sounds unlikely. The doxygen doc is not generated during the build phase right now, it's used the doc generated in the package. Looks like the problem is trying to parse the doxygen xml. I can see the same error in the devel project, but just fir i586. So maybe it's something related to libxml or maybe the package wxWidgets-3_2-doc-xml? Okay, I can reproduce it just in a branch project: https://build.opensuse.org/project/show/home:dgarcia:branches:X11:wxWidgets With the latest doxygen and wxWidgets-3_2 package. So it should be the wxWidgets doc generated with newer doxygen. There's even a bug report upstream that looks related: https://github.com/wxWidgets/Phoenix/issues/2241 https://build.opensuse.org/package/view_file/devel:tools/source-highlight/source-highlight.spec uses doxygen and is pulled in by wxPython That would be the only path to influence the build. ah, so it is about https://build.opensuse.org/package/view_file/openSUSE:Factory/wxWidgets-3_2/wxWidgets-3_2.spec Created attachment 869357 [details]
doc diff
Thanks, we have already stumbled over this: https://github.com/wxWidgets/Phoenix/issues/2414 I have emailed Dimitri, doxygen author, to find out his position. If I understand correctly, in the meantime we could just stick with 1.9.6 or disable rebuild_sip in python-wxPython.spec, if desirable. Reassigning to me. Thank you for looking into. Doxygen is not only used for the documentation, but also to generate the XML files required for the automatic code generation xml -> etg -> sip. Upstream ships a full wxWidgets with wxPython, and during the very long wxWigets 3.2/wxPython 4.2 beta phase there where frequent binary incompatible changes happened. As openSUSE builds the wxPython bindings on top of the system wxWidgets package, the wxWigets:doc _multibuild builds the wxWidgets*-doc-xml package using doxygen. The wxPython package then consumes the wxWigets*-doc-xml package to (re)generate the etg and sip files. Note the "ln -sf /usr/share/doc/packages/wxWidgets-3_2-doc-xml /tmp/wxxml/docs/doxygen/out/xml". The wxPython does not require doxygen. AFAIR the "export DOXYGEN" was/is a workaround to silence misleading output from the build.py script. The only noteworthy (i.e. non-whitespace) change is the following hunk: --- old//usr/share/doc/packages/wxWidgets-3_2-doc-xml/glcanvas_8h.xml 2023-05-26 22:09:51.000000000 +0200 +++ new//usr/share/doc/packages/wxWidgets-3_2-doc-xml/glcanvas_8h.xml 2023-09-07 11:49:16.000000000 +0200 @@ -1,5 +1,5 @@ <?xml version='1.0' encoding='UTF-8' standalone='no'?> -<doxygen xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="compound.xsd" version="1.9.6" xml:lang="en-US"> +<doxygen xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="compound.xsd" version="1.9.8" xml:lang="en-US"> <compounddef id="glcanvas_8h" kind="file" language="C++"> <compoundname>glcanvas.h</compoundname> <innerclass refid="classwx_g_l_attribs_base" prot="public">wxGLAttribsBase</innerclass> @@ -7,10 +7,10 @@ <innerclass refid="classwx_g_l_context_attrs" prot="public">wxGLContextAttrs</innerclass> <innerclass refid="classwx_g_l_context" prot="public">wxGLContext</innerclass> <innerclass refid="classwx_g_l_canvas" prot="public">wxGLCanvas</innerclass> - <sectiondef kind="enum"> + <sectiondef kind="enum"> <memberdef kind="enum" id="glcanvas_8h_1a39fca1837c5ce7715cbf571669660c13" prot="public" static="no" strong="no"> <type></type> - <name>@22</name> + <name></name> <enumvalue id="glcanvas_8h_1a39fca1837c5ce7715cbf571669660c13a8801f84d6ba28f32bd7fe0081776a409" prot="public"> Replicated in home:pgajdos:doxygen. For now I have reverted to 1.9.6 in devel:tools to incorporate reproducible.patch into Factory/ALP. I got a reply from the doxygen author, pasting it here for completeness. -------------------------8<------------------------------- Hi Petr, Looks like some python script, unknown to me, is used to process the XML = output produced by doxygen. Hard to tell for me if 1) The XML is correct, but the script makes wrong assumptions and is not = robust. 2) The XML is wrong. One way to check is to validate it against the XML = schema. If that is ok, the script needs fixing, otherwise doxygen needs = fixing. Regards, Dimitri ------------------------->8------------------------------- (In reply to Petr Gajdos from comment #15) > I got a reply from the doxygen author, pasting it here for completeness. > > -------------------------8<------------------------------- > > Hi Petr, > > Looks like some python script, unknown to me, is used to process the XML = > output produced by doxygen. > > Hard to tell for me if > 1) The XML is correct, but the script makes wrong assumptions and is not = > robust. > 2) The XML is wrong. One way to check is to validate it against the XML = > schema. If that is ok, the script needs fixing, otherwise doxygen needs = > fixing. > > Regards, > Dimitri > ------------------------->8------------------------------- Upstream (doxygen) issues: https://github.com/doxygen/doxygen/issues/10071 https://github.com/doxygen/doxygen/issues/10072 TLDR: The new output is correct. The difficulty lies in processing the output of both old and new doxygen correctly. Thank you Stefan. Christoph updated doxygen to 1.10.0 in Factory meanwhile. I believe this bug can be closed. |
Created attachment 869270 [details] build log python-wxPython fails to build with doxygen 1.9.7. Now the most interesting thing is wxPython isn't pulling doxygen as a build requirement. The key is in build.py that has a function for pulling doxygen for your system and some lines in the spec exporting where the doxygen binary would be in your system. The package probably should be updated for pulling wxpython properly or not using it at all (remove spec lines most likely?). To make things more fun, this issue is not reproducible if you create a devel project and add both packages. It's only triggered when doxygen is in staging project or already accepted. doxygen 1.9.7 got accepted because one of the times in the staging project everything built correctly. My wild guess is somehow build.py pulled an old version of doxygen. So please, update wxpython to either pull doxygen properly or not to use it all. I'm attaching a failed build log.