Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 201674 - Review Request: codeblocks
Summary: Review Request: codeblocks
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jason Tibbitts
QA Contact: Fedora Package Reviews List
URL:
Whiteboard:
Depends On:
Blocks: FE-ACCEPT
TreeView+ depends on / blocked
 
Reported: 2006-08-08 08:34 UTC by Dan Horák
Modified: 2007-12-10 16:45 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2006-09-13 20:59:54 UTC
Type: ---
Embargoed:
kevin: fedora-cvs+


Attachments (Terms of Use)

Description Dan Horák 2006-08-08 08:34:12 UTC
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

Comment 1 Jason Tibbitts 2006-08-13 04:03:03 UTC
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?

Comment 2 Ralf Corsepius 2006-08-13 04:56:37 UTC
(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.



Comment 3 Dan Horák 2006-08-13 07:30:41 UTC
(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?

Comment 4 Dan Horák 2006-08-13 07:33:01 UTC
(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.

Comment 5 Dan Horák 2006-08-13 07:41:21 UTC
> > 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.

Comment 6 Dan Horák 2006-08-13 09:25:27 UTC
(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.

Comment 7 Michael Schwendt 2006-08-13 10:41:04 UTC
> 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

Comment 8 Dan Horák 2006-08-13 11:07:29 UTC
(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.

Comment 9 Dan Horák 2006-08-14 05:52:37 UTC
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


Comment 10 Jason Tibbitts 2006-08-15 19:37:55 UTC
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.


Comment 11 Dan Horák 2006-08-15 20:02:20 UTC
(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

Comment 12 Dan Horák 2006-08-15 20:40:32 UTC
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


Comment 13 Jason Tibbitts 2006-08-15 20:58:03 UTC
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.)

Comment 14 Dan Horák 2006-08-16 07:58:21 UTC
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


Comment 15 Dan Horák 2006-08-16 12:34:37 UTC
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


Comment 16 Dan Horák 2006-08-21 09:02:43 UTC
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

Comment 17 Dan Horák 2006-09-04 11:16:27 UTC
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


Comment 18 Jason Tibbitts 2006-09-09 23:55:49 UTC
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.


Comment 19 Dan Horák 2006-09-10 10:10:14 UTC
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


Comment 20 Jason Tibbitts 2006-09-12 16:27:37 UTC
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

Comment 21 Dan Horák 2006-09-13 07:09:55 UTC
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).

Comment 22 Jason Tibbitts 2006-09-13 15:18:05 UTC
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.

Comment 23 Dan Horák 2006-09-13 15:39:25 UTC
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.

Comment 24 Dan Horák 2006-09-13 17:59:14 UTC
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.

Comment 25 Jason Tibbitts 2006-09-13 18:36:44 UTC
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.


Comment 26 Dan Horák 2006-09-13 20:59:54 UTC
I saw the warning too.

imported and built, FC-5 branch requested

Comment 27 Dan Horák 2007-12-10 09:15:11 UTC
Package Change Request
======================
Package Name: codeblocks
New Branches: EL-4 EL-5

Comment 28 Kevin Fenzi 2007-12-10 16:45:24 UTC
cvs done.


Note You need to log in before you can comment on or make changes to this bug.