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.