Spec URL: http://fedora.danny.cz/codeblocks.spec SRPM URL: http://fedora.danny.cz/codeblocks-1.0-0.1.2824svn.src.rpm Description: Code::Blocks is a free C++ IDE built specifically to meet the most demanding needs of its users. It was designed, right from the start, to be extensible and configurable. Built around a plugin framework, Code::Blocks can be extended with plugin libs. It includes a plugin wizard, so you can compile your own plugins. Notes: - rpmlint output is clean, there are only false positives (about no doc in subpackages and *.c and *.h files in main package, but they are used as templates for new projects) - there is a patch (codeblocks-plugins.patch) to install plugins not under /usr/share/codeblocks but in /usr/lib/codeblocks - a hack to disarm the rpath is applied as patch (codeblocks-rpath.patch) after running autotools - builds in devel on i386
This failed to build for me: + chmod a+x bootstrap acinclude.m4 src/update + ./bootstrap ./bootstrap: line 43: libtoolize: command not found error: Bad exit status from /var/tmp/rpm-tmp.76866 (%build) Looks like a BuildRequires: libtool is needed. Also, I note that the naming guidelines require that a SVN checkout be dated instead of using the revision number, but I'm not sure that requirement makes much sense. Is there a reason why you disabled parallel make? If so, you should note that in the spec. (This takes ages to build single-threaded.) Ah, the build just failed again: ++ -O2 -ffast-math -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -o .libs/codeblocks app.o appglobals.o compilersettingsdlg.o crashhandler.o dlgabout.o dlgaboutplugin.o environmentsettingsdlg.o main.o prefix.o printdlg.o scriptconsole.o splashscreen.o startherepage.o -pthread -L/builddir/build/BUILD/codeblocks/src/src/wxAUI /builddir/build/BUILD/codeblocks/src/src/wxAUI/.libs/libwxaui.a -L/builddir/build/BUILD/codeblocks/src/sdk /builddir/build/BUILD/codeblocks/src/sdk/.libs/libcodeblocks.so -lwx_gtk2u_xrc-2.6 -lwx_gtk2u_qa-2.6 -lwx_gtk2u_html-2.6 -lwx_gtk2u_adv-2.6 -lwx_gtk2u_core-2.6 -lwx_baseu_xml-2.6 -lwx_baseu_net-2.6 -lwx_baseu-2.6 -lpthread -ldl -Wl,--rpath -Wl,/usr/lib /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to `cairo_xlib_surface_create_for_bitmap' /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to `cairo_xlib_surface_create' /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to `cairo_xlib_surface_set_size' collect2: ld returned 1 exit status make[3]: *** [codeblocks] Error 1 make[3]: Leaving directory `/builddir/build/BUILD/codeblocks/src/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/builddir/build/BUILD/codeblocks/src/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/builddir/build/BUILD/codeblocks/src' make: *** [all-recursive] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.41997 (%build) Not sure what to do at this point. Perhaps a missing BR: on some X or cairo library?
(In reply to comment #1) > This failed to build for me: > > + chmod a+x bootstrap acinclude.m4 src/update > + ./bootstrap "chmod a+x"'ing acinclude.m4 doesn't make any sense. acinclude.m4's are not executable. They are source files.
(In reply to comment #1) > This failed to build for me: > > + chmod a+x bootstrap acinclude.m4 src/update > + ./bootstrap > ./bootstrap: line 43: libtoolize: command not found > error: Bad exit status from /var/tmp/rpm-tmp.76866 (%build) > > Looks like a BuildRequires: libtool is needed. OK, BR for all autotools are needed :-) > > Also, I note that the naming guidelines require that a SVN checkout be dated > instead of using the revision number, but I'm not sure that requirement makes > much sense. I think that for SVN repos there should be possible to use revision number. With CVS there is no such possibility so the dates must be used. It makes also possible to track the official "nightly build" which use revision numbers. > Is there a reason why you disabled parallel make? If so, you should note that > in the spec. (This takes ages to build single-threaded.) It is only an omission from some bug hunting. > Ah, the build just failed again: > > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to > `cairo_xlib_surface_create_for_bitmap' > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to `cairo_xlib_surface_create' > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to `cairo_xlib_surface_set_size' > > Not sure what to do at this point. Perhaps a missing BR: on some X or cairo > library? I have no idea too, all required libraries should be taken to the linker via wxWidgets libraries. Is this from x86_64 rawhide? How much up-to-date was the rawhide?
(In reply to comment #2) > > + chmod a+x bootstrap acinclude.m4 src/update > > + ./bootstrap > > "chmod a+x"'ing acinclude.m4 doesn't make any sense. > > acinclude.m4's are not executable. They are source files. Cut'n'paste from upstream, fixed.
> > Ah, the build just failed again: > > > > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to > > `cairo_xlib_surface_create_for_bitmap' > > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to `cairo_xlib_surface_create' > > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to > `cairo_xlib_surface_set_size' > > > > Not sure what to do at this point. Perhaps a missing BR: on some X or cairo > > library? > > I have no idea too, all required libraries should be taken to the linker via > wxWidgets libraries. Is this from x86_64 rawhide? How much up-to-date was the > rawhide? It builds clean on rawhide from 20060810 on i386, now I am updating my build system and will try it later today.
(In reply to comment #3) > > Ah, the build just failed again: > > > > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to > > `cairo_xlib_surface_create_for_bitmap' > > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to `cairo_xlib_surface_create' > > /usr/lib64/libgdk-x11-2.0.so.0: undefined reference to > `cairo_xlib_surface_set_size' > > > > Not sure what to do at this point. Perhaps a missing BR: on some X or cairo > > library? > > I have no idea too, all required libraries should be taken to the linker via > wxWidgets libraries. Is this from x86_64 rawhide? How much up-to-date was the > rawhide? No linking problem on just updated rawhide, so it could be a x86_64 problem.
> I think that for SVN repos there should be possible to use > revision number. With CVS there is no such possibility so the > dates must be used. Not true. Surely you could check out from CVS using a branch tag or revision. Please use the date for SVN checks, too, and optionally put the revision number at the right. Like: codeblocks-1.0-0.1.20060731svn.src.rpm or: codeblocks-1.0-0.1.20060731svn2824.src.rpm or: codeblocks-1.0-0.1.20060803cvs.src.rpm There is no necessity to squeeze SVN revision numbers or CVS tags/revs into the package Release. Instead, add a comment in your spec on how to check out the included source code. The most interesting information about pre-releases is the date, which is independent from whether the source is maintained in SVN or CVS or a different VCS. Further info: http://fedoraproject.org/wiki/Packaging/NamingGuidelines#head-d97a3f40b6dd9d2288206ac9bd8f1bf9b791b22a
(In reply to comment #7) > > I think that for SVN repos there should be possible to use > > revision number. With CVS there is no such possibility so the > > dates must be used. > > Not true. Surely you could check out from CVS using a branch tag > or revision. I meant situation between tagged revisions as the tags in CVS are not usually created after every commited change. > > Please use the date for SVN checks, too, and optionally put the > revision number at the right. Like: > > codeblocks-1.0-0.1.20060731svn.src.rpm > or: > codeblocks-1.0-0.1.20060731svn2824.src.rpm OK, I will use the above (date + rev) > or: > codeblocks-1.0-0.1.20060803cvs.src.rpm > > There is no necessity to squeeze SVN revision numbers or CVS tags/revs > into the package Release. Instead, add a comment in your spec on how > to check out the included source code. > > The most interesting information about pre-releases is the date, which > is independent from whether the source is maintained in SVN or CVS or > a different VCS. Using the date versus revision depends on the the style of upstream development. And I see using the revisions useful as the revision is exact identification of the development state and should be visible. When placed in the spec file, it would be hidden from most users.
Updated SRPM URL: http://fedora.danny.cz/codeblocks-1.0-0.2.20060812svn2840.src.rpm Updated spec URL: http://fedora.danny.cz/codeblocks.spec Changes: - added autotools to BR - changed Release per NamingGuidelines
Seems to be some 64-bit problems: RPM build errors: File not found by glob: /var/tmp/codeblocks-1.0-0.2.20060812svn2840.fc6-root-mockbuild/usr/lib64/*.so.* File not found: /var/tmp/codeblocks-1.0-0.2.20060812svn2840.fc6-root-mockbuild/usr/lib64/codeblocks/plugins File not found: /var/tmp/codeblocks-1.0-0.2.20060812svn2840.fc6-root-mockbuild/usr/lib64/codeblocks/plugins/libastyle.so (and so on for many files). Looks like the upstream source wants to install into /usr/lib regardless of what configure is told.
(In reply to comment #10) > Seems to be some 64-bit problems: > > RPM build errors: > File not found by glob: > /var/tmp/codeblocks-1.0-0.2.20060812svn2840.fc6-root-mockbuild/usr/lib64/*.so.* > File not found: > /var/tmp/codeblocks-1.0-0.2.20060812svn2840.fc6-root-mockbuild/usr/lib64/codeblocks/plugins > File not found: > /var/tmp/codeblocks-1.0-0.2.20060812svn2840.fc6-root-mockbuild/usr/lib64/codeblocks/plugins/libastyle.so > (and so on for many files). > > Looks like the upstream source wants to install into /usr/lib regardless of what > configure is told. > Should be a libtool issue I think as the Makefile.am files are very clean and all are used on the build system to create the "executable" files. Can you check how is defined libdir in Makefile.in and Makefile in some src/plugins/ subdir? I have libdir = @libdir@/@PACKAGE@/plugins in Makefile.in and libdir = ${exec_prefix}/lib/codeblocks/plugins in Makefile
I have updated the spec file with libdir defined when running configure. Can you try to rebuild the sources using this spec file? I will upload the SRPM tomorrow. Updated spec URL: http://fedora.danny.cz/codeblocks.spec
No problem; I rebuilt with that spec and everything seems OK. Aside from the rpmlint warnings that you indicated were false positives (which I agree with, BTW), there is: W: codeblocks setup-not-quiet W: codeblocks mixed-use-of-spaces-and-tabs (You have to run rpmlint on the SRPM to see this.) The former is IMHO not a blocker but can be cured by passing -q to %setup. The latter can be fixed by deciding whether you're going to use tabs or spaces for indentation and stick with it. (You mostly use tabs but use spaces in %package devel and the Requires: bit of %package contrib.)
Updated SRPM URL: http://fedora.danny.cz/codeblocks-1.0-0.4.20060812svn2840.src.rpm Updated spec URL: http://fedora.danny.cz/codeblocks.spec Changes: - make setup section quiet - use only tabs for indentation - define libdir in configure
Updated SRPM URL: http://fedora.danny.cz/codeblocks-1.0-0.5.20060815svn2854.src.rpm Updated spec URL: http://fedora.danny.cz/codeblocks.spec Changes: - updated to revision 2854
Updated SRPM URL: http://fedora.danny.cz/codeblocks-1.0-0.6.20060820svn2882.src.rpm Updated spec URL: http://fedora.danny.cz/codeblocks.spec Changes: - updated to revision 2882 - added missing Requires: pkgconfig for devel subpackage
Updated SRPM URL: http://fedora.danny.cz/codeblocks-1.0-0.7.20060902svn2944.src.rpm Updated spec URL: http://fedora.danny.cz/codeblocks.spec Changes: - updated to revision 2944
I can't check the upstream source. Could you provide a quick script in the package for grabbing the source from the repository and generating the tarball? I know if won't compare the same due to directory timestamps but I can at least do a recursive diff. Any reason why you don't use the %configure macro instead of listing out that long configure line? /usr/lib64/codeblocks seems to be unowned. You don't seem to install the desktop file properly. Generally you should use desktop-file-install. X source files match upstream (can't check) * package meets naming and packaging guidelines. * specfile is properly named, is cleanly written and uses macros consistently. * dist tag is present. * build root is correct. * license field matches the actual license. * license is open source-compatible. License text included in package. * BuildRequires are proper. * compiler flags are appropriate. * %clean is present. * package builds in mock (development, x86_64). * package installs properly * debuginfo package looks complete. * rpmlint has only ignorable complaints. * final provides and requires are sane: codeblocks-1.0-0.7.20060902svn2944.fc6.x86_64.rpm libastyle.so()(64bit) libautosave.so()(64bit) libclasswizard.so()(64bit) libcodeblocks.so.0()(64bit) libcodecompletion.so()(64bit) libcompiler.so()(64bit) libdebuggergdb.so()(64bit) libdefaultmimehandler.so()(64bit) libscriptedwizard.so()(64bit) libtodo.so()(64bit) codeblocks = 1.0-0.7.20060902svn2944.fc6 = /sbin/ldconfig libatk-1.0.so.0()(64bit) libcairo.so.2()(64bit) libcodeblocks.so.0()(64bit) libgdk-x11-2.0.so.0()(64bit) libgdk_pixbuf-2.0.so.0()(64bit) libglib-2.0.so.0()(64bit) libgmodule-2.0.so.0()(64bit) libgobject-2.0.so.0()(64bit) libgtk-x11-2.0.so.0()(64bit) libpango-1.0.so.0()(64bit) libpangocairo-1.0.so.0()(64bit) libwx_baseu-2.6.so.0()(64bit) libwx_baseu-2.6.so.0(WXU_2.6)(64bit) libwx_baseu_net-2.6.so.0()(64bit) libwx_baseu_net-2.6.so.0(WXU_2.6)(64bit) libwx_baseu_xml-2.6.so.0()(64bit) libwx_baseu_xml-2.6.so.0(WXU_2.6)(64bit) libwx_gtk2u_adv-2.6.so.0()(64bit) libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) libwx_gtk2u_core-2.6.so.0()(64bit) libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) libwx_gtk2u_core-2.6.so.0(WXU_2.6.3)(64bit) libwx_gtk2u_html-2.6.so.0()(64bit) libwx_gtk2u_html-2.6.so.0(WXU_2.6)(64bit) libwx_gtk2u_qa-2.6.so.0()(64bit) libwx_gtk2u_qa-2.6.so.0(WXU_2.6)(64bit) libwx_gtk2u_xrc-2.6.so.0()(64bit) libwx_gtk2u_xrc-2.6.so.0(WXU_2.6)(64bit) codeblocks-contrib-1.0-0.7.20060902svn2944.fc6.x86_64.rpm libbyogames.so()(64bit) libcb_koders.so()(64bit) libcodesnippets.so()(64bit) libcodestat.so()(64bit) libdragscroll.so()(64bit) libenvvars.so()(64bit) libexporter.so()(64bit) libhelp_plugin.so()(64bit) libkeybinder.so()(64bit) libprofiler.so()(64bit) libwxsmith.so()(64bit) codeblocks-contrib = 1.0-0.7.20060902svn2944.fc6 = codeblocks = 1.0-0.7.20060902svn2944.fc6 libcodeblocks.so.0()(64bit) libwx_baseu-2.6.so.0()(64bit) libwx_baseu-2.6.so.0(WXU_2.6)(64bit) libwx_baseu_net-2.6.so.0()(64bit) libwx_baseu_xml-2.6.so.0()(64bit) libwx_gtk2u_adv-2.6.so.0()(64bit) libwx_gtk2u_adv-2.6.so.0(WXU_2.6)(64bit) libwx_gtk2u_core-2.6.so.0()(64bit) libwx_gtk2u_core-2.6.so.0(WXU_2.6)(64bit) libwx_gtk2u_core-2.6.so.0(WXU_2.6.2)(64bit) libwx_gtk2u_html-2.6.so.0()(64bit) libwx_gtk2u_html-2.6.so.0(WXU_2.6)(64bit) libwx_gtk2u_qa-2.6.so.0()(64bit) libwx_gtk2u_xrc-2.6.so.0()(64bit) libwx_gtk2u_xrc-2.6.so.0(WXU_2.6)(64bit) codeblocks-devel-1.0-0.7.20060902svn2944.fc6.x86_64.rpm codeblocks-devel = 1.0-0.7.20060902svn2944.fc6 = codeblocks = 1.0-0.7.20060902svn2944.fc6 libcodeblocks.so.0()(64bit) pkgconfig * %check is not present; no test suite upstream. * shared libraries are added to the regular linker search paths; ldconfig is called as necessary and unversioned .so files are in the -devel package. * package is not relocatable. X owns the directories it creates. * doesn't own any directories it shouldn't. * no duplicates in %files. * file permissions are appropriate. * scriptlets OK (ldconfig) * code, not content. * documentation is small, so no -docs subpackage is necessary. * %docs are not necessary for the proper functioning of the package. * header files are content used by the package. * pkgconfig file is in the -devel package. * no libtool .la droppings. X desktop file does not seem to be installed properly.
Updated SRPM URL: http://fedora.danny.cz/codeblocks-1.0-0.8.20060909svn2965.src.rpm Updated spec URL: http://fedora.danny.cz/codeblocks.spec - update to revision 2965 - use %%configure macro - properly install the desktop file - update the mime database after install and uninstall - do not own only %%{_libdir}/codeblock/plugins, but also %%{_libdir}/codeblock - added a script for retrieving and packing a revision from the SVN repo
You should use "svn export" instead of "svn co" to generate your tarballs. The .svn directories are useless in this context. Deleting all of the .svn directories from the tarball gives me a clean compare except for one file: diff -ur a/codeblocks/src/plugins/contrib/help_plugin/help_plugin.cpp b/codeblocks/src/plugins/contrib/help_plugin/help_plugin.cpp --- a/codeblocks/src/plugins/contrib/help_plugin/help_plugin.cpp 2006-08-19 04:03:12.000000000 -0500 +++ b/codeblocks/src/plugins/contrib/help_plugin/help_plugin.cpp 2006-08-18 10:24:58.000000000 -0500 @@ -20,7 +20,7 @@ * Program URL : http://www.codeblocks.org * * $Id: help_plugin.cpp 2875 2006-08-18 15:24:58Z thomasdenk $ -* $Date: 2006-08-18 17:24:58 +0200 (Pá, 18 srp 2006) $ +* $Date: 2006-08-18 10:24:58 -0500 (Fri, 18 Aug 2006) $ */ #include "help_plugin.h" I guess you'd have to set LANG and TZ when checking out as well. Or perhaps there's a flag to svn that could be used to suppress that kind of expansion. In any case, this isn't a big deal although when the time comes to check this package in, you should use a tarball generated with "svn export" to get rid of the needless ".svn" directories. The %configure line looks much simpler now. /usr/lib64/codeblocks is properly owned now. The desktop file looks to be properly installed. I recall that Rex is trying to get changes made to the desktop file policy with regards to using "--vendor fedora" but at this point I don't know what the fuss is about and what you have done is in accordance with the current packaging guidelines. So all of the issues I had are fixed; just be sure to get rid of those .svn directories in your tarball. APPROVED
Thnaks for the review. The .svn directory (at least the top-level) is required by src/tools/autorevision utility which incorporates the revision number into the codeblocks binary (creates src/sdk/autorevision.h).
That would seem to be somewhat broken; svn export should give a buildable tree (and it seemed to work well for me but I suppose it didn't pick up the embedded version.) And it's kind of weird for some software to care about the VCS that contains it. What if I wanted to pull it into a git tree for local modification? In any case, if it actually needs that stuff then I suppose you have to include it.
I have just tested recompile without the .svn directories - it works. But I think I able to generate the header file directly from the spec file (both date and revision are there) and disable compiling and running the autorevision utility. I will create an updated version of SRPM.
I agree that distributing .svn dirs is not optimal. So here is updated package Updated SRPM URL: http://fedora.danny.cz/codeblocks-1.0-0.9.20060909svn2965.src.rpm Updated spec URL: http://fedora.danny.cz/codeblocks.spec - added workaround that disables interaction with subversion during the build - the script for retrieving the sources sets LANG and TZ and is used to package the sources included in the SRPM Jason, please, check on your system whether it still builds. On my FC4 it is OK. Then I will use this package as starting point for Extras.
Yes, this builds fine and I think it's ready to check in. The codeblocks-getsvn script does elicit another rpmlint warning: W: codeblocks strange-permission codeblocks-getsvn 0755 but that is bogus as well.
I saw the warning too. imported and built, FC-5 branch requested
Package Change Request ====================== Package Name: codeblocks New Branches: EL-4 EL-5
cvs done.