GNOME Bugzilla – Bug 402159
totem build fails
Last modified: 2007-01-29 19:50:41 UTC
With g-d-u 0.9.1 trying to build totem 2.17.90 fails with (cd de/ && \ `which xml2po` -e -p \ "${d}de/de.po" \ "${d}C/totem.xml" > totem.xml.tmp && \ cp totem.xml.tmp totem.xml && rm -f totem.xml.tmp) xsltproc -o totem-C.omf --stringparam db2omf.basename totem --stringparam db2omf .format 'docbook' --stringparam db2omf.dtd "-//OASIS//DTD DocBook XML V4.1.2//EN " --stringparam db2omf.lang C --stringparam db2omf.omf_dir "/opt/gnome2/share/om f" --stringparam db2omf.help_dir "/opt/gnome2/share/gnome/help" --stringparam db 2omf.omf_in "`pwd`/./totem.omf.in" `/usr/bin/pkg-config --variable db2omf gnome- doc-utils` C/totem.xml db2omf: Invalid subject code "GNOME|Multimedia" in /usr/src/packages/BUILD/totem -2.17.90/help/./totem.omf.in. make[2]: *** [totem-C.omf] Error 10 After reverting to g-d-u 0.8.0, the package builds just fine.
It doesn't look like the db2omf.scrollkeeper_cl argument is being passed. This is probably because you're using an old copy of gnome-doc-utils.make that's sitting around in your source tree. Try running 'gnome-doc-prepare -f' to replace that file with the one from 0.9.1.
That seems to have fixed the problem, but I had to rerun aclocal, autoconf, and automake as well. Since I was building from a tarball release, not from SVN that's a really bad idea. Does this mean that packages need to check for a specific version of g-d-u in configure from now on? Or is it possible to restore compatibility with 0.8.x? The situation right now is not acceptable IMHO.
OK, I see the problem. Tarballs ship with a specific version of gnome-doc-utils.make, but they don't ship with a copy of db2omf.xsl. So we can't reasonably expect that the versions of these two files will be in sync. I've just committed a change the skips the category code checks if db2omf.scrollkeeper_cl is not passed in. This should fix this issue. Could you install gnome-doc-utils from SVN trunk and try building the tarball again with the tarball's supplied gnome-doc-utils.make?
That fixed it for good, yes. Thanks for the quick service.