Description of problem: During F15 armv7 bootstrap it was detected that gtkmm24 FTBFS in Fedora 15. Version-Release number of selected component (if applicable): gtkmm24-2.24.0-3.fc15 How reproducible: always Steps to Reproduce: 1. mock -r fedora-15-x86_64 gtkmm24-2.24.0-3.fc15.src.rpm 2. 3. Actual results: Can't open perl script "/usr/share/glibmm-2.4/doctool/doc-install.pl": No such file or directory Expected results: package built Additional info:
for documentation of bug state: upstream bug - https://bugzilla.gnome.org/show_bug.cgi?id=648860 workaround http://jkastner.fedorapeople.org/glibmm24-2.28.0-1.fc15.0.arm1/glibmm24-2.28.0-1.fc15.0.arm1.src.rpm in configure is following snippet, which appeared first in glibmm in fc15 and which i don't understand (yet) how to invoke (convice configure to install it and therefore avoid workaround above) MMDOCTOOLDIR='${top_srcdir}/docs' if test 'xdocs' != 'x'; then DIST_DOCTOOLS_TRUE= DIST_DOCTOOLS_FALSE='#' else DIST_DOCTOOLS_TRUE='#' DIST_DOCTOOLS_FALSE= fi
gtkmm24-2.4.2-1.fc16 seems to use internal doc-install.pl, maybe the right solution is pushing that to f15 as well?
I obviously meant gtkmm24-2.24.2-1.fc16
Yes, updating to 2.24.2 would certainly fix it. The question is, do we want to also push out an update for the primary arches? If not, then the other alternative would be to just do a build with Karsen Hopp's targeted fix (http://pkgs.fedoraproject.org/gitweb/?p=gtkmm24.git;a=commit;h=1da1c73) and not push it out as an update through Bodhi. That way, the ARM guys can use the srpm and we can avoid introducing additional update churn for F15 users. Haïkel, any opinions?
Same issue also hits gconfmm26 which is also failing on missing doc-install.pl. It's a bit confusing. Is doc-install.pl supposed to be installed or not? This is a problem for the arm secondary arch where F15 is rebuild from source.
doc-install.pl used to be part of glibmm and used to be installed in /usr/share/glibmm-2.4/doctool/. At one point, upstream decided that it's better to distribute the script in mm-common. mm-common is only meant to be needed when building from git (and rolling tarballs) and shouldn't be used when building from tarballs. To make that work, doc-install.pl which now lives in mm-common is also distributed in every mm module's tarball. That way, newly rolled tarballs use their internal doc-install.pl and build fine. A nice change, but the oversight was that it broke older tarballs that relied on glibmm's doc-install.pl. The issue was complicated by the fact that the change happened very late in glibmm 2.28 cycle and most other mm module tarballs didn't get respinned in time for F15.
Thanks. Picture clear. Found some more F15 packages failing on doc-install.pl. Updated list: gconfmm26-2.28.2-2.fc15 goocanvasmm-0.15.4-3.fc15 gtkmm24-2.24.0-3.fc15 libvtemm-0.23.1-2.fc15 Most packages which have been built so far seem to use their own bundled doc-install.pl and only one (goocanvasmm2) are using the copy from mm-common. It is possible there is additional packages having this issue but which are also failing for other reasons (build dependenceis not met etc).
Ping? Would be really good if some decision can be made on how to address this on the affected packages, primarily gconfmm26 and gtkmm24.
I guess I'll need to volunteer; doesn't look like we're reaching any decision here. This is what I'm planning to do: In F15, build a patched glibmm24 that duplicates mm-common's doc-install.pl in /usr/share/glibmm-2.4/doctool/. This should be enough to make all the packages listed in comment #8 build. In F16, everything should already build fine with latest glibmm24, except for gconfmm26. I'll look into fixing it upstream and getting a new tarball out which we can then use in Fedora.
The workaround is in glibmm24-2.28.1-2.fc15 and should be enough to make the rest of the packages build. Henrik, is it OK with you if I don't push it out as an update through Bodhi on the primary arches?
Submitted a gconfmm patch upstream: https://bugzilla.gnome.org/show_bug.cgi?id=648860
A koji build is minimum requirement to assign an NVR to the change. But if you don't mind then please file an update but don't push it to stable. This prevents koji from garbage collecting the build, and also provides a better record should there be an additional update needed for glibmm24 during the remaining life of F15.
Right, glibmm24-2.28.1-2.fc15 is the koji NVR for the build and you can get the SRPM from there. If you rebuild it for ARM, the rest of the packages should hopefully build with glibmm24-2.28.1-2.fc15 in the buildroots.
It built fine and long dependency chains are now being walked by the builders. Many thanks!
You're welcome.