Updated to newest Lazarus-upstream version:

SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.14-1.src.rpm
Spec: http://www.cnoc.nl/fpc/lazarus.spec

I want to review this, but I cannot get the upstream sources.  The URL in the
specfile gives me back HTML and I can't find a download link for an upstream
tarball.

It's a download from SourceForge.net. Here's the link again:
http://prdownloads.sourceforge.net/lazarus/lazarus-0.9.14-1.tar.gz

You only have to select a mirror, on the right of the html you receive. 

I also placed it on my own website: http://www.cnoc.nl/fpc/lazarus-0.9.14-0.tar.gz

If you use "download.sourceforge.net" (or dl.sf.net if you hate typing) then you
get a direct download without having to select a mirror.  Some have had better
luck using easynews.dl.sf.net.

I've updated the package to upstream version 0.9.14-1 and also changed the
download-url

Spec: http://www.cnoc.nl/fpc/lazarus.spec
SPRM: http://www.cnoc.nl/fpc/lazarus-0.9.14-2.src.rpm

Added the ability to compile gtk 2 applications:

Spec: http://www.cnoc.nl/fpc/lazarus.spec
SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.14-3.src.rpm

Not building on devel x86_64.

Free Pascal Compiler version 2.0.2 [2006/03/13] for x86_64
Copyright (c) 1993-2005 by Florian Klaempfl
Target OS: Linux for x86-64
Compiling dbflaz.pas
Compiling registerdbf.pas
Fatal: Can't find unit Dbf
Fatal: Compilation aborted
make[2]: *** [dbflaz.ppu] Error 1

Thanks for looking at it!

The problem you've found is more a bug in fpc, actually. The tDbf package isn't
included/compiled on X86_64 and powerpc in fpc-2.0.2.

Here's a workaround. It only compiles the basic IDE without the extra packages,
like tDbf. Maybe it's even better, since some of the extra components are
somewhat buggy. And if an end-user needs them, he can install them himself.

Spec: http://www.cnoc.nl/fpc/lazarus.spec
SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.14-4.src.rpm

File found but not packaged: /usr/bin/startlazarus

Are all those Required packages needed for running lazarus?

Remove strip fom %build, let rpmbuild do that.

Your comments say enable gtk2, but you Require gtk+, which is gtk1. Is that
intended?

Fixed the lost file and removed the strip. I didn't even knew that rpmbuild did
that.

The only packages which are needed to run lazarus are: fpc-src, gtk+ and gdk-pixbuf.

But if you want to compile a program in lazarus, you need the compiler (fpc) +
binutils, the -devel packages and in most cases glibc. If you want to debug your
program you also need gdb.
So those packages are stricly not needed for running lazarus, but since most
users will use it to make and compile programs, I included them. (They also
aren't detected by rpmbuild as dependencies)

Lazarus is able to create gtk1 and gtk2 applications. For Lazarus itself the
default is 'gtk1', since the LCL-gtk1-interface is more stable. So Lazarus needs
gtk1-to run. (it's a gtk1-application) 

But I enabled the option to make gtk2-applications with Lazarus. But you're
right, gtk2 must also be added as buildrequirement for that. 
I won't add it to the normal requirements, though, since applications are
default build as gtk1. If some user switches that to gtk2, he can think of
himself that he has to install gtk2(-devel).

Spec: http://www.cnoc.nl/fpc/lazarus.spec
SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.14-5.src.rpm

Upstream has released version 0.9.16. Should I update the package, or are some
people busy reviewing 0.9.14, who won't like to do their work over again?

(In reply to comment #11)
> Upstream has released version 0.9.16. Should I update the package, or are some
> people busy reviewing 0.9.14, who won't like to do their work over again?

Please update. Reviewing the latest version is preferred.

Ok, done:

Spec: http://www.cnoc.nl/fpc/lazarus.spec
SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.16-1.src.rpm

Why is the debuginfo package disabled?

Manual copying of the readme and license is not needed with the %doc macro in
the %files section which copies automatically. Merely specify %doc
lazarus/COPYING* etc.

You can drop the Requires: gdk-pixbuf, gtk+ and glibc, because rpm figures out
the library dependencies by itself. (rpm -q --requires to see them)

Excuses for my very late reply. But I missed the email and thought that no-one
had looked at this package again....

(In reply to comment #14)
> Why is the debuginfo package disabled?

Actually, I don't know. Someone told me to do so, because an empty package was
generated. I tried without that code, and that empty package isn't there
anymore. So' I'll remove it.

> Manual copying of the readme and license is not needed with the %doc macro in
> the %files section which copies automatically. Merely specify %doc
> lazarus/COPYING* etc.

Fixed

> You can drop the Requires: gdk-pixbuf, gtk+ and glibc, because rpm figures out
> the library dependencies by itself. (rpm -q --requires to see them)

Fixed

In the meantime a new version is released, so I updated the version to 0.9.18. 

And it seems that rpmbuild doesn't strip the executables. The RPM is HUGE now.
Where can I find more information about strip and rpmbuild?

SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.18-1.src.rpm
SPEC: http://www.cnoc.nl/fpc/lazarus.spec

> (In reply to comment #14)
> > Why is the debuginfo package disabled?
> 
> Actually, I don't know. Someone told me to do so, because an empty package was
> generated. I tried without that code, and that empty package isn't there
> anymore. So' I'll remove it.
> 
The debuginfo package is not empty, but at ~500K relatively small. Which leads
to the next point: 
> 
> And it seems that rpmbuild doesn't strip the executables. The RPM is HUGE now.
> Where can I find more information about strip and rpmbuild?
> 
Not sure about documentation, but it is clear from the strip scripts in
/usr/lib/rpm that rpm only strips ELF binaries that have the execute bit set.



I see everything is in $(LIBDIR), executable, documentation, pascal modules, and
all. Are any of the make targets suitable for splitting this up?

I'll have a look at the strip-issue...

About $(LIBDIR)... As you can see in the .spec file I don't even use the
make-tools for installing... I could use them, but then it insist in placing
everything in $(PREFIX)/share. (which is incorrect, it also contains the
pre-compiled .ppu files, which are platform specific)

But as Lazarus is constructed now, it's very difficult to split things up. Well,
I could place the executables somewhere else. maybe that that's an idea. And I
could move the documentation. But that's not possible using any make targets,
only by copying them manually, and changing some lazarus-settings, so it knows
where to find those files.

I've updated to lazarus-0.9.20. Please review.

SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.20-1.src.rpm

More devel x86_64 build error fun:

+ cd lazarus
+ fpcmake
Processing Makefile.fpc
Error: Target "linux", package "rtl" not found

It also happens on i386, I discovered.

The problem is that I re-create the makefile so that it's installs in /ust/lib,
but that fails. I'll investigate it.

Could you retry with this version?

SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.20-2.src.rpm

(In reply to comment #21)
> Could you retry with this version?
> 
> SRPM: http://www.cnoc.nl/fpc/lazarus-0.9.20-2.src.rpm

Same error as comment 19

Sigh, I made a type. Could you try again? (download the same file again)?

type=typo ;)

This build error looks like an actual x86_64 one:

RPM build errors:
    File not found: /var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib64/lazarus

Does fpcmake have some concept of autoconf $(libdir)? Even patched it has
hardcoded /usr/lib/ which we don't want for arch dependent things on x86_64.

fpcmake uses the settings in Makefile.fpc to generate the makefile. If you add a
hardcoded 'lib/lazarus' in the Makefile.fpc, fpcmake places that literally in
the makefile.

I changed the patch, so that it doesn't use 'lib/lazarus', but '$(_lib)/lazarus'
and added '_LIB={%_lib}' to the make-command. This should solve the
build-problem on 64-bit systems. Can you try again? (same link?) 

Builds this time, and seems to run.

rpmlint to look at:
E: lazarus statically-linked-binary /usr/lib64/lazarus/tools/svn2revisioninc
Why is this static?

E: lazarus-debuginfo empty-debuginfo-package
debuginfo package empty, due in part to:
W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/lazarus
W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/startlazarus
W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/lazbuild
etc.


Are the things in %(libdir)/lazarus/debian  needed?

Not a lawyer, but the modified LGPL does seem to give additional permission.
Seems to be in Debian experimental, for what that's worth. Does this need futher
license review?

(In reply to comment #27)
> Builds this time, and seems to run.

Good to hear.

> rpmlint to look at:
> E: lazarus statically-linked-binary /usr/lib64/lazarus/tools/svn2revisioninc
> Why is this static?

All freepascal-programs are static. The (released) fpc-compilers don't support
dynamic-linking. And for pascal-languages this isn't important in most cases. A
pascal program for example is (almost) never linked to glibc.

> E: lazarus-debuginfo empty-debuginfo-package
> debuginfo package empty, due in part to:
> W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/lazarus
> W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/startlazarus
> W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/lazbuild
> etc.

Yes, for some strange reason strip doesn't strip those binaries. And I have no
idea why not. The rpm-script simply doesn't recognize them as binaries... I'll
investigate further

> Are the things in %(libdir)/lazarus/debian  needed?

No. ;) Shall I remove them from the package?

> Not a lawyer, but the modified LGPL does seem to give additional permission.
> Seems to be in Debian experimental, for what that's worth. Does this need futher
> license review?

This same license is used by the fpc-package itself. In principle it's LGPL, but
since fpc can only link programs static, the LGPL license won't work. That's
because the LGPL permits to use libraries, unmodified, in non-GPL applications,
but only if they are linked in *dynamical*. The exception/change in this
modified LGPL is that you can also link the binary static.

I had a better look:
> rpmlint to look at:
> E: lazarus statically-linked-binary /usr/lib64/lazarus/tools/svn2revisioninc
> Why is this static?

This is explained above, but it's a little bit more complicated. For example
lazarus itself is dyn. linked, but that's because it's linked to some
C-libraries. svn2revisioninc doesn't depend on any c-libs, so it's static.

> E: lazarus-debuginfo empty-debuginfo-package
> debuginfo package empty, due in part to:
> W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/lazarus
> W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/startlazarus
> W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/lazbuild

If I run rpmlint I do not get these problems. I checked manually and the lazarus
executable is stripped, and there's also a debug-package of 22 MB.
But I use version 2.1.1 of the compiler. It could be a compiler-problem in
version 2.0.4, or it could be a compiler problem on 64-bits systems. I'll try
tonight with 2.0.4 on a 32-bit system.
(the problem could be that the debuginfo isn't generated properly)

Is anything happening with this ticket?

Rebuilt 0.9.20-2 on devel x86_64, it doesn't generate debuginfo.

From mock's build.log:

extracting debug info from
/var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib64/lazarus/tools/svn2revisioninc
Failed to write file: invalid section entry size
eu-strip: while writing
'/var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib/debug/usr/lib64/lazarus/tools/svn2revisioninc.d
ebug': invalid section entry size
extracting debug info from
/var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib64/lazarus/lazarus
Failed to write file: invalid section entry size
eu-strip: while writing
'/var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib/debug/usr/lib64/lazarus/lazarus.debug':
invalid
 section entry size
extracting debug info from
/var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib64/lazarus/startlazarus
Failed to write file: invalid section entry size
eu-strip: while writing
'/var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib/debug/usr/lib64/lazarus/startlazarus.debug':
in
valid section entry size
extracting debug info from
/var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib64/lazarus/lazbuild
Failed to write file: invalid section entry size
eu-strip: while writing
'/var/tmp/lazarus-0.9.20-2.fc7-root-mockbuild/usr/lib/debug/usr/lib64/lazarus/lazbuild.debug':
invali
d section entry size
0 blocks


I would appreciate at least a comment in the spec that indicates stripping seems
to be broken on x86_64.



rpmlint:

W: lazarus invalid-license GPL, MPL and modified LGPL
W: lazarus-debuginfo invalid-license GPL, MPL and modified LGPL
Ignore, Accepting this license.

W: lazarus setup-not-quiet
Optional.

W: lazarus mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 10)
Fix please.

E: lazarus non-executable-script /usr/lib64/lazarus/debian/prerm.ex 0644
E: lazarus non-executable-script /usr/lib64/lazarus/debian/postinst.ex 0644
E: lazarus non-executable-script /usr/lib64/lazarus/debian/init.d.ex 0644
E: lazarus non-executable-script /usr/lib64/lazarus/debian/emacsen-remove.ex 0644
E: lazarus non-executable-script /usr/lib64/lazarus/debian/emacsen-install.ex 0644
E: lazarus non-executable-script /usr/lib64/lazarus/debian/postrm.ex 0644
E: lazarus non-executable-script
/usr/lib64/lazarus/tools/install/cross_unix/debian_crosswin32/postrm 0644
E: lazarus non-executable-script /usr/lib64/lazarus/debian/preinst.ex 0644
We're not doing debs, remove directory please.

E: lazarus zero-length
/usr/lib64/lazarus/components/codetools/examples/scanexamples/empty.inc
E: lazarus zero-length /usr/lib64/lazarus/lcl/interfaces/carbon/carbonimages.lrs
Ignore.

E: lazarus devel-dependency gdk-pixbuf-devel
Ignore, required to use lazarus.

W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/tools/svn2revisioninc
W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/lazarus
W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/startlazarus
W: lazarus unstripped-binary-or-object /usr/lib64/lazarus/lazbuild
E: lazarus-debuginfo empty-debuginfo-package
The mentioned strip problem. Please document in the spec.

E: lazarus statically-linked-binary /usr/lib64/lazarus/tools/svn2revisioninc
Given it's pascal and you indicated these are static, ignore.



Ran lazarus, seemed OK from a cursory glance.

Doesn't use %find_lang, but it's a bunch of .po files dropped in a dir lazarus
uses. Ignore.

tools/install/rpm  comes with some older spec templates. What to do about them,
given that's not the .spec we are using?


Good:
Follows naming guidelines
Licenses
Source matches
Builds on x86_64
Owns all directories, no duplicate files
Uses macros
%defattr good
%clean good

Ping!

BTW ver. 0.9.22 is out.

Ok, I've tried it again. now fpc 2.2.0 is out I had to wait for lazarus 0.9.24
to be released. That's the case now. I've updated Lazarus to version 0.9.24, and
looked at the comments above.

srpm: http://www.cnoc.nl/fpc/lazarus-0.9.24-1.fc9.src.rpm

Changelog:
- Removed files specific for debian
- Updated to Lazarus v 0.9.24
- Changed desktop-file categories
- Disabled the debug-package for x86_64 again, see bug 337051
- If the debuginfo-packages is disabled, strip the executables manually
- Require fpc version 2.2.0
- Added -q to setup-macro
- Added OPT='-gl' option in build-section, to make sure that the debuginfo is
generated by the compiler
- Removed explicit creation of {buildroot}{_mandir}/man1 and
{buildroot}{_datadir}/applications
- Lazarus executable is renamed to lazarus-ide (changed upstream)

This time I also know what's wrong with the debuginfo and the
unstripped-binaries. fpc 2.2.0 contains a bug (bugzilla 337051) which causes
problems with building the debuginfo on x86_64. As long as this isn't fixed I've
disabled the debug-package as a workaround. Side effect of removing the
debug-package is that the executables are not stripped. So I added that manually.

About the older .spec files, I could remove them. But they are part of of the
upstream package. And can be used to build non-fedora rpm's.

In next releases the older .spec files will be updated according to this spec
file, btw.

Joost, you might want to e-mail John Mahowald directly and ping him. He might
not have noticed the update, after months

My understanding is that John doesn't really have a lot of time at the moment. 
I've pinged him on IRC as well; maybe I can raise him there.  But if we can't
get a response soon, assign this ticket back to nobody@fedoraproject.org and
clear the fedora-review flag so it goes back to the list of new review tickets.

I've talked to him on IRC a few times, and he said he was working on it. I'll
try to catch him again and ask if I could better try to find someone else to review.

So this is back in the pool.  Perhaps I'll find the time to look at it if nobody
beats me to it.  If the package in comment 34 is the one you'd like reviewed,
please say so or go ahead and drop another package.

However, some things I didn't see mentioned before.  One warning from
desktop-file-install during the package build:
+ desktop-file-install --vendor fedora --dir
/var/tmp/lazarus-0.9.24-1.fc9-root-mockbuild/usr/share/applications
lazarus/install/lazarus.desktop
/var/tmp/lazarus-0.9.24-1.fc9-root-mockbuild/usr/share/applications/fedora-lazarus.desktop:
warning: value "lazarus.png" for key "Icon" in group "Desktop Entry" is an icon
name with an extension, but there should be no extension as described in the
Icon Theme Specification if the value is not an absolute path

and come rpmlint complaints:
  lazarus.src: W: mixed-use-of-spaces-and-tabs (spaces: line 1, tab: line 10)
I'm not generally concerned about these.

  lazarus.src: W: invalid-license GPL, MPL
  lazarus.src: W: invalid-license modified LGPL
Please use proper License tags according to
http://fedoraproject.org/wiki/Licensing and
http://fedoraproject.org/wiki/Packaging/LicensingGuidelines.  If the "modified
LGPL" in use doesn't fit any existing tags and something like "LGPLv2+ with
exceptions" isn't close enough then you will need to have the licensing experts
assign a new tag for you.

  lazarus.x86_64: E: non-executable-script 
   /usr/lib64/lazarus/components/lazreport/doc/cvs2cl.pl 0644
  lazarus.x86_64: E: non-executable-script 
   /usr/lib64/lazarus/examples/trayicon/createbundle.sh 0644
  lazarus.x86_64: E: non-executable-script 
   /usr/lib64/lazarus/components/lazreport/tools/localize.sh 0644
Are you sure these shouldn't be executable?  What will call them?

  lazarus.x86_64: E: non-executable-script 
   /usr/lib64/lazarus/tools/install/cross_unix/debian_crosswin32/postrm 0644
I thought that according to comments above that this would be going away.

  lazarus.x86_64: W: ldd-failed /usr/lib64/lazarus/tools/svn2revisioninc
I think this was covered in a discussion above about fpc output always being
static, and should be OK.

(In reply to comment #38)
> So this is back in the pool.  Perhaps I'll find the time to look at it if nobody
> beats me to it.  If the package in comment 34 is the one you'd like reviewed,
> please say so or go ahead and drop another package.

Great that you want to help me to improve this package.

> However, some things I didn't see mentioned before.  One warning from
> desktop-file-install during the package build:

Fixed

>   lazarus.src: W: invalid-license GPL, MPL
>   lazarus.src: W: invalid-license modified LGPL
> Please use proper License tags according to
> http://fedoraproject.org/wiki/Licensing and
> http://fedoraproject.org/wiki/Packaging/LicensingGuidelines.  If the "modified
> LGPL" in use doesn't fit any existing tags and something like "LGPLv2+ with
> exceptions" isn't close enough then you will need to have the licensing experts
> assign a new tag for you.

I've asked on the fedora-legal-list and they said I should use the "LGPL+ with
exceptions" tag with a note that it was in fact the GNU classpath-exception
 
>   lazarus.x86_64: E: non-executable-script 
>    /usr/lib64/lazarus/components/lazreport/doc/cvs2cl.pl 0644
>   lazarus.x86_64: E: non-executable-script 
>    /usr/lib64/lazarus/examples/trayicon/createbundle.sh 0644
>   lazarus.x86_64: E: non-executable-script 
>    /usr/lib64/lazarus/components/lazreport/tools/localize.sh 0644
> Are you sure these shouldn't be executable?  What will call them?

First script is obsolete, but I added the execute-flag anyway. Second is a
script used on OS/X only, so that shoudn't be executable. And the last script
should indeed have the executable-flag set. Fixed.


>   lazarus.x86_64: E: non-executable-script 
>    /usr/lib64/lazarus/tools/install/cross_unix/debian_crosswin32/postrm 0644
> I thought that according to comments above that this would be going away.

I didn't saw these files. Removed them.
 
>   lazarus.x86_64: W: ldd-failed /usr/lib64/lazarus/tools/svn2revisioninc
> I think this was covered in a discussion above about fpc output always being
> static, and should be OK.

I've made a new package with these changes: (build with f7, I have no other
system available here atm):  http://www.cnoc.nl/fpc/lazarus-0.9.24-2.fc7.src.rpm

The OS X-only script should probably be '%exclude'd from the final file listing ?

(In reply to comment #40)
> The OS X-only script should probably be '%exclude'd from the final file listing ?

I'm a little bit reluctant to do so. Lazarus is an IDE for multiple platforms,
an has several tools for each platform to run on properly. I woudn't be
surprised if there are more files than this one which are in fact for another
operating system.  Maybe for example also some readme's and such. 

Should I now search the complete tree for all those files and exclude them? And
do that for every release?

(In reply to comment #41)
> (In reply to comment #40)
> > The OS X-only script should probably be '%exclude'd from the final file
listing ?
> 
> I'm a little bit reluctant to do so. Lazarus is an IDE for multiple platforms,
> an has several tools for each platform to run on properly. I woudn't be
> surprised if there are more files than this one which are in fact for another
> operating system.  Maybe for example also some readme's and such. 
> 
> Should I now search the complete tree for all those files and exclude them? And
> do that for every release?

Good point. If there are multiple files like that, then if only for consistency,
it's better to just include them all. The users could be trusted to figure out
which script applies to their environment.

Come one, so many people have looked at this one already. It should be an easy
review now...

Of course you're correct; I keep meaning to revisit some of these really old
review tickets but I have had trouble finding the time lately.  I will try to
revisit this as soon as I have sufficient time to do so, but of course anyone
else is welcome to take care of it first.

Well, I wrote up quite a bit of commentary but lost it in a firefox crash.  Let
me try to get at least something written down here.

I built the package from comment 39 and found the following in the build output:
  warning: File listed twice: 
   /usr/lib64/lazarus/components/lazreport/doc/cvs2cl.pl
  warning: File listed twice: 
   /usr/lib64/lazarus/components/lazreport/tools/localize.sh
Unfortunately it's not possible to just list the two files whose permissions you
want to change with %attr specifiers in the %files section, since that means
that you can't use a simple glob to include everything below %{_libdir}/%{name}.
 It's far simpler to just chmod the files in your %install section.

rpmlint output was all covered earlier in this ticket and is not problematic.

This comment:
  # Disable the debuginfo packagefor x86_64
  # For more info, see fpc-bug 337051
could use a bit of clarification; the ticket is in redhat bugzilla, not fpc's
bug tracker.  Also, since things have changed there recently, does this package
need any changes?  It would be nice for the debug package weirdness to go away.

I've fixed the files-entries and removed the debuginfo-hack, but now it won't
build in mock, because it still uses the 'old' fpc-fc8 packages.
So I'll have to find out if the new packages will get into fc9 automatically, or
that I have to do something to achieve that...

Well, F9 is frozen now.  If you have something that you think really needs to
get into the F9 release, you can contact rel-eng@fedoraproject.org and ask that
your build be tagged.  Otherwise it will go out as an update once F9 is released.

Rawhide doesn't start moving again for another week or so.

Well, we've had a full release and rawhide is suitably raw now.  If you post
that updated package I'll be happy to finish up this review.

Now it doesn't  build because the symlink /usr/lib64/libglib.so does not exist.
But an /usr/lib/libglib.so does exist.
Afaik this file was part of the glibc-devel package but now it isn't anymore. I
have to find out what happened and where this file is now. 
You could try to build it yourself:
http://www.cnoc.nl/fpc/lazarus-0.9.24-3.fc9.src.rpm
I'm off on vacation tomorrow. I'll be back june 20th

Actually that package seems to build OK for me in current rawhide, except that
things crap out at the very end of the process:

extracting debug info from
/var/tmp/lazarus-0.9.24-3.fc10-root-mockbuild/usr/lib64/lazarus/tools/svn2revisioninc
extracting debug info from
/var/tmp/lazarus-0.9.24-3.fc10-root-mockbuild/usr/lib64/lazarus/lazarus
/usr/lib/rpm/debugedit:
canonicalization unexpectedly shrank by one character

which is completely bewildering, but according to comments in bug 304121 it's
caused by a doubled slash somewhere making it into the debug data.  I removed
the trailing slash from the FPCDIR export in the %build section and it builds
fine now.

Honestly all of my complaints have been taken care of.  The newly-enabled
debuginfo package doesn't actually include the source, probably due to many
complaints like the following:

/usr/lib/rpm/debugedit:
/var/tmp/lazarus-0.9.24-3.fc10-root-mockbuild/usr/lib64/lazarus/lazarus: Wrong
directory table index 3

but honestly I'm not going to hold this up because fpc and rpm-build disagree on
how to extract debuginfo data.  Maybe you can figure out what's going on after
this is imported.

Honestly, the only issue I can see is that trailing slash, which you can
trivially fix up when you check in.

APPROVED

New Package CVS Request
=======================
Package Name: lazarus
Short Description: Lazarus Component Library and IDE for Freepascal
Owners: joost
Branches: F-9
InitialCC: joost
Cvsextras Commits: yes

cvs done.

Thanks for all the help, especially to Jason Tibbitts, offcourse.

lazarus-0.9.24-4.fc9 has been submitted as an update for Fedora 9

lazarus-0.9.24-4.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

ackage Change Request
======================
Package Name: lazarus
New Branches: EL-4 EL-5
Owners: joost

CVS Done