Hide Forgot
Spec Name or Url: http://www.cnoc.nl/fpc/lazarus.spec SRPM Name or Url: http://www.cnoc.nl/fpc/lazarus-0.9.12-1.src.rpm Description: Lazarus is a free and opensource RAD tool for freepascal using the lazarus component library - LCL, which is also included in this package. Lazarus provides a development-studio like Delphi, including components for quick database-access, XML, RTTI and much more. An application written with lazarus can be compiled for different interfaces, like GTK1, GTK2, Win32, WINCE and Carbon (OS/X) on different platforms (sparc, i386, x86-64, ppc, arm, POWER5) Without changing a single line of code and without using any framework like Mono/.Net/Java
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