Bug 996

Summary: gnome-doc-utils: do_compile failed
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Dexuan Cui <dexuan.cui>
Component: coreAssignee: Dexuan Cui <dexuan.cui>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: Medium CC: liang.li2, liangliang.wang, meta.mr.watcher, meta.watcher, scott.a.garman, sgw, yi.zhao
Version: unspecified   
Target Milestone: 1.1   
Hardware: x86   
OS: Multiple   
Whiteboard: Scott helped to make a fix (05/May/2011)
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Dexuan Cui 2011-04-18 23:47:59 UTC
http://autobuilder.yoctoproject.org:8010/builders/nightly-external/builds/96/steps/shell_19/logs/stdio

| xsltproc -o gnome-doc-xslt-de.omf --stringparam db2omf.basename gnome-doc-xslt --stringparam db2omf.format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML V4.4//EN" --stringparam db2omf.lang de --stringparam db2omf.omf_dir "/usr/share/omf" --stringparam db2omf.help_dir "/usr/share/gnome/help" --stringparam db2omf.omf_in "/srv/home/pokybuild/poky-slave/nightly-external/build/build/tmp/work/armv7a-poky-linux-gnueabi/gnome-doc-utils-0.20.5-r0/gnome-doc-utils-0.20.5/doc/xslt/gnome-doc-xslt.omf.in"  ../../xslt/docbook/omf/db2omf.xsl de/gnome-doc-xslt.xml || { rm -f "gnome-doc-xslt-de.omf"; exit 1; }
| http://www.oasis-open.org/docbook/xml/4.4/dbgenent.mod:1: parser error : Content error in the external subset
| HTTP/1.1 200 OK
| ^
| http://www.oasis-open.org/docbook/xml/4.4/dbgenent.mod:1: validity error : All markup of the conditional section is not in the same entity
| HTTP/1.1 200 OK
| ^
| http://www.oasis-open.org/docbook/xml/4.4/dbgenent.mod:1: parser error : Content error in the external subset
| HTTP/1.1 200 OK
|    ^
| unable to parse C/gnome-doc-xslt.xml
| make[2]: *** [gnome-doc-xslt-C.omf] Error 1
Comment 1 Dexuan Cui 2011-04-18 23:56:34 UTC
This happened to 0.20.5-r0, but actually 0.20.4-r0 has the same issue:
http://autobuilder.yoctoproject.org:8010/builders/nightly-external/builds/95/steps/shell_19/logs/stdio

I can't reproduce the issue locally so I didn't catch the issue when upgrading it to 0.20.5.

Looks even on autobuilder, the bug doesn't always happen, e.g.,  this is a log:
we can see "package gnome-doc-utils-0.20.5-r0: task do_compile: Started" in http://autobuilder.yoctoproject.org:8010/builders/nightly-external/builds/96/steps/shell_3/logs/stdio
Comment 2 Dexuan Cui 2011-04-19 00:30:21 UTC
(In reply to comment #1)
> This happened to 0.20.5-r0, but actually 0.20.4-r0 has the same issue:
> http://autobuilder.yoctoproject.org:8010/builders/nightly-external/builds/95/steps/shell_19/logs/stdio
> I can't reproduce the issue locally so I didn't catch the issue when upgrading
> it to 0.20.5.
> Looks even on autobuilder, the bug doesn't always happen, e.g.,  this is a log:
> we can see "package gnome-doc-utils-0.20.5-r0: task do_compile: Started" in
> http://autobuilder.yoctoproject.org:8010/builders/nightly-external/builds/96/steps/shell_3/logs/stdio
I meant "package gnome-doc-utils-0.20.5-r0: task do_compile: Succeeded".


gnome-doc-utils depends on gnome-doc-utils-native, but in the cases of failure, looks gnome-doc-utils-native was not built at all and libxslt-native and libxml2-native were not built, either.
I don't know the cause yet.
Comment 3 Dexuan Cui 2011-05-04 22:15:44 UTC
Scott has kindly helped to give a fix: add an option --nonet to xsltproc.

The issue happens on the external autobuilder which has direct access to the Internet and can download the DTDs, but the DTDs are not compatible with gnome-doc-utils's some .xml files.

Scott: possibly something changed on the DTD oasis server, or maybe the new version of gnome-doc-utils upgraded looks for a different DTD than was used previously.
Comment 4 liang li 2011-05-08 19:12:55 UTC
This error also happened on nightly build (20110506-4) which led to qemuppc sato,sato-sdk images build failed,logs link below:
http://autobuilder.pokylinux.org:8010/builders/nightly-external/builds/117/steps/shell_14/logs/stdio
git info :
856a5e496b7ddd814f6a94552d02074f0ab30842
Comment 5 Liang Wang 2011-05-08 23:54:33 UTC
The same issue also happen on nightly build for qemumips(core-image-sato core-image-sato-dev core-image-sato-sdk). Please see log file below. (git commit 856a5e496b7ddd814f6a94552d02074f0ab30842)

http://autobuilder.yoctoproject.org:8010/builders/nightly-external/builds/117/steps/shell_10/logs/stdio


| http://www.oasis-open.org/docbook/xml/4.4/dbhierx.mod:236: validity error : All markup of the conditional section is not in the same entity
| <!--end of setinfo.element-->]]>
|     ^
| http://www.oasis-open.org/docbook/xml/4.4/dbhierx.mod:236: parser error : Content error in the external subset
| <!--end of setinfo.element-->]]>
|         ^
| unable to parse de/gnome-doc-xslt.xml
| make[2]: *** [gnome-doc-xslt-de.omf] Error 1
| make[2]: Leaving directory `/srv/home/pokybuild/poky-slave/nightly-external/build/build/tmp/work/mips-poky-linux/gnome-doc-utils-0.20.5-r1/gnome-doc-utils-0.20.5/doc/xslt'
| make[1]: *** [all-recursive] Error 1
| make[1]: Leaving directory `/srv/home/pokybuild/poky-slave/nightly-external/build/build/tmp/work/mips-poky-linux/gnome-doc-utils-0.20.5-r1/gnome-doc-utils-0.20.5/doc'
| make: *** [all-recursive] Error 1
| ERROR: oe_runmake failed
| ERROR: Function 'do_compile' failed (see /srv/home/pokybuild/poky-slave/nightly-external/build/build/tmp/work/mips-poky-linux/gnome-doc-utils-0.20.5-r1/temp/log.do_compile.25209 for further information)
| ERROR: Function 'do_compile' failed (see /srv/home/pokybuild/poky-slave/nightly-external/build/build/tmp/work/mips-poky-linux/gnome-doc-utils-0.20.5-r1/temp/log.do_compile.25209 for further information)
NOTE: package gnome-doc-utils-0.20.5-r1: task do_compile: Failed
ERROR: Task 4204 (/srv/home/pokybuild/poky-slave/nightly-external/build/meta/recipes-gnome/gnome/gnome-doc-utils_0.20.5.bb, do_compile) failed with exit code '1'
Comment 6 Scott Garman 2011-05-09 09:53:58 UTC
In my previous fix there was a makefile template that was being included from a different top-level directory which I missed. It included calls to xsltproc that needed the -nonet option.

I have just submitted a pull request to Saul with what I believe should be the final fix for this.
Comment 7 Yi Zhao 2011-05-09 23:38:12 UTC
With 20110506-4 build (git commit 856a5e496b7ddd814f6a94552d02074f0ab30842), this issue also caused x86_64-arm toolchain and i686-powerpc toolchain build failures. But i686-arm toolchain and x86_64-powerpc toolcahin were build success.

The error message was same as above. For more details, please see
http://autobuilder.pokylinux.org:8010/builders/nightly-external/builds/117/steps/shell_42/logs/stdio  (For i686-powerpc)
and
http://autobuilder.pokylinux.org:8010/builders/nightly-external/builds/117/steps/shell_47/logs/stdio  (For x86_64-arm)
Comment 8 Dexuan Cui 2011-05-12 18:52:22 UTC
(In reply to comment #6)
> In my previous fix there was a makefile template that was being included from a
> different top-level directory which I missed. It included calls to xsltproc
> that needed the -nonet option.
> I have just submitted a pull request to Saul with what I believe should be the
> final fix for this.

Thanks a lot for Scott's fixes:
http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f20edfe129ae69420f22c857d4100891282932a8
http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=ed18794c37338788a5b18f222c36d21793b1a523
Comment 9 Dexuan Cui 2011-05-12 18:53:50 UTC
(In reply to comment #8)
> (In reply to comment #6)
> > In my previous fix there was a makefile template that was being included from a
> > different top-level directory which I missed. It included calls to xsltproc
> > that needed the -nonet option.
> > I have just submitted a pull request to Saul with what I believe should be the
> > final fix for this.
> Thanks a lot for Scott's fixes:
> http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=f20edfe129ae69420f22c857d4100891282932a8
> http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=ed18794c37338788a5b18f222c36d21793b1a523

Let me mark the bug as VERIFIED since I don't see the bug in recent nightly logs.