Answering to Olav post about my plans for the gnome buildbot: the more slaves, the better :). However, it is obvious that I cannot review all build errors on all modules for all the slaves, besides it makes not much sense… for me, the good way to go here would be that project maintainers and core developers (at least) subscribe to the modules they are experts on and whenever they receive notification that any of these projects fail to build, drop by the buildbot and check what’s going on with it. I’m sure they’ll know better and will realize sooner in most cases what’s going on there, so they can fix the problem in the repository if needed or give feedback to us so we can fix the build for that module (for example using appropriate build flags, installing missing dependencies, etc.).
Btw, I removed the test coverage stuff to build scrollkeeper successfully at least once, so modules failing to build due to its dependency on this module can build. Unfortunately, I see that gnome-doc-utils failing to build is also causing a lot of build problems in other modules. Is there anyone who can help us out to fix this build error?:
xsltproc -o "C/db2html-bibliography.xml"
--stringparam basename "db2html-bibliography"
--stringparam xsl_file "/usr/local/buildslave/gnome/work/src/gnome-doc-utils/doc/xslt/../../xslt/docbook/html/db2html-bibliography.xsl"
"./xsldoc-docbook.xsl" "C/db2html-bibliography.xsldoc"
db2html-bibliography: No documentation for template mode l10n.format.mode
See complete Log here.
I fixed that build error last night 🙂
Unfortunately, there is a further error (in make check I believe) that was beyond me last night 🙁
Great, thanks! 🙂
Unfortunately, the error I get now when building is not in make check, but still in make, what prevents it from being installed (it would not matter that much if it was in make check):
Making all in xslt
make[3]: Entering directory `/usr/local/buildslave/gnome/work/src/gnome-doc-utils/doc/xslt’
[…]
xsltproc -o gnome-doc-xslt-C.omf –stringparam db2omf.basename gnome-doc-xslt –stringparam db2omf.format ‘docbook’ –stringparam db2omf.dtd “-//OASIS//DTD DocBook XML V4.4//EN” –stringparam db2omf.lang C –stringparam db2omf.omf_dir “/usr/local/buildslave/gnome/work/bin/share/omf” –stringparam db2omf.help_dir “/usr/local/buildslave/gnome/work/bin/share/gnome/help” –stringparam db2omf.omf_in “/usr/local/buildslave/gnome/work/src/gnome-doc-utils/doc/xslt/gnome-doc-xslt.omf.in” –stringparam db2omf.scrollkeeper_cl “`scrollkeeper-config –pkgdatadir`/Templates/C/scrollkeeper_cl.xml” ../../xslt/docbook/omf/db2omf.xsl C/gnome-doc-xslt.xml || { rm -f “gnome-doc-xslt-C.omf”; exit 1; }
Running xsldoc checks
The stylesheet db-common calls an undefined template l10n.gettext
Full details here:
http://build.gnome.org:8080/gnome-doc-utils/gnome-doc-utils-RHEL5/builds/18/step-gnome-doc-utils%20build/0
Re: “the good way to go here would be that project maintainers and core developers (at least) subscribe to the modules they are experts on”
Is there a feature to receive a mail when a build fails for a module?
No yet, but you can subscribe to the RSS feed of failed builds. We will probably add email notification too in the future.
re: the new failure.
Yep, that was the next error I saw after I fixed the first. Unfortunately, it was getting late and it’s a bit beyond my knowledge. I managed to hack around it only to run into another error. I’ve ping the Grand Master shaunm, but so far, nothing.
Oh, and once I finish work, I’ll make an effort to replace scrollkeeper with Rarian in jhbuild, which should remove the scrollkeeper problem (since, you know, different package).
(BTW, you’re catchpa is pretty difficult to read. It’d be useful to have a “regenerate” button next to it)
Thanks for looking after this. If you need to make any changes to jhbuild modulesets warn me (I’ll likely need to do some updates in that case).
Thanks also for the hint about the catchpa, I’ll ask our sysadmin to look for a fix to this.
I love that there are RSS and Atom feeds but Firefox can’t seem to subscribe to them – nothing happens when clicking the Subscribe button.
The captcha here is far too difficult.
Yeah, that is fixed already. The problem has to do with some binary chars that jhbuild inserts to format text in console. I fixed that some time ago, but there were still some build logs with these chars inside, I’ve cleaned all logs and rebuild again, that should make feeds work anywhere again.
Thanks for warning.