Spec URL: http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/kazehakase.spec SRPM URL: http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/kazehakase-0.4.3-1.src.rpm Description: Kazehakase is a Web browser which aims to provide a user interface that is truly user-friendly & fully customizable.
Builds fine in mock(FC-6). * /usr/lib/kazehakase is not owned by the package * the desktop file categories should be: Categories=Network;Application;X-Fedora;
(In reply to comment #1) > Builds fine in mock(FC-6). > * /usr/lib/kazehakase is not owned by the package Oops... I will fix this. > * the desktop file categories should be: > Categories=Network;Application;X-Fedora; Both categories (Application, X-Fedora) are deprecated and warned or treated as error from desktop-fiele-utils >= 0.11 (FC-devel) and should not used any longer (this is applied to at FC5/6).
Uploaded. http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/kazehakase.spec http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/kazehakase-0.4.3-2.src.rpm * Wed Dec 13 2006 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> - 0.4.3-2 - Forgot to own %%{_libdir}/%%{name}, fixing.
I would appreciate it if someone would review this...
Package doesn't build in an ordinary user environment on FC6: # rpmbuild -ba kazehakase.spec ... libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make[4]: *** [GtkPromptService.lo] Error 1 make[4]: *** Waiting for unfinished jobs.... libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' Also, I will not review nor approve any package which runs any of the autotools during building, esp. if they are incorrecly applied, such as in this case (Hint: aclocal, version of autoconf being used).
Well, would you attach the full build log, Ralf? I cannot catch only from your comment. I use rawhide, and I cannot check "ordinary" FC6 environ. Note: mockbuild on FC6/devel i386 succeeds. also, for me "ordinary" rpmbuild succeeds on FC-devel. And as this srpm "touch"es all files which are not needed to be regenerated, rebuilding this srpm should succeed.
Created attachment 144168 [details] Mock build log of kazehakase 0.4.3-2 on FC6 i386 Well, it is true that mockbuild of 0.4.3-2 on FC6 i386 succeeds. Maybe rebuilding failure is related with your settings or something else?
Created attachment 144198 [details] Log of build failure on FC6
(In reply to comment #7) > Maybe rebuilding failure is related with your settings > or something else? Without having looked into details (I am scarce on time, ATM), my guess would be the breakdown related to you running the autotools, so may-be something related to * The package uses autoconf-2.60a, while FC6 has 2.59. * My user environment also has autoconf/automake/libtool installed, a mock environment doesn't. * They are using autoconf-2.60a (a beta version), so they might also be using a beta of libtool. rpm and/or you running autoconf can interfere.
(In reply to comment #9) > (In reply to comment #7) > > Maybe rebuilding failure is related with your settings > > or something else? Urgh, I have to apologize - This was a DUE (Dumb User Error) on my part. The machine I was building on didn't have g++ installed, sorry. But ... after having corrected this ... the package still doesn't build: ... kz-mozlauncher.cpp:69: error: prototype for 'nsresult KzContentHandler::Show(nsIHelperAppLauncher*, nsISupports*, PRBool)' does not match any in class 'KzContentHandler' kz-mozlauncher.h:57: error: candidate is: virtual nsresult KzContentHandler::Show(nsIHelperAppLauncher*, nsISupports*, PRUint32) /usr/include/firefox-1.5.0.9/xpcom/nsCOMPtr.h: In instantiation of 'nsDerivedSafe<nsIHelperAppLauncher>': kz-mozlauncher.cpp:81: instantiated from here
(In reply to comment #10) > But ... after having corrected this ... the package still doesn't build: Well, again please attach your full build log and config.h on failure rebuild? I have only FC-devel i386 and I can check if this can be rebuild on FC-6 only by mockbuild and only on i386. My mockbuild log on FC-6 i386 is in comment #7.
Created attachment 144252 [details] config.h of mockbuild 0.4.3-2 on FC6 i386 I attach config.h created during mockbuild of kazehakase 0.4.3-2 on FC6 i386.
Created attachment 144253 [details] config.log of mockbuild 0.4.3-2 on FC6 i386 Samely, config.log
Umm, I checked firefox-devel-1.5.0.9-1.fc6, however, it seems that this should succeed in rebuilding. /usr/include/firefox-1.5.0.9/exthandler/nsIHelperAppLauncherDialog.h expects that the last argument of KzContentHandler::Show should be PRUint32 --------------------------------------------------- 65 NS_IMETHOD Show(nsIHelperAppLauncher *aLauncher, nsISupports *aContext, PRUint32 aReason) = 0; --------------------------------------------------- Then kazehakase-0.4.3/src/mozilla/kz-mozlauncher.cpp says: --------------------------------------------------- 66 NS_IMETHODIMP KzContentHandler::Show(nsIHelperAppLauncher *aLauncher, 67 nsISupports *aContext, 68 #ifdef MOZ_NSIHELPERAPPLAUNCHERDIALOG_NSPRBOOL_ 69 PRBool aForced) 70 #else 71 PRUint32 aForced) 72 #endif --------------------------------------------------- this means that MOZ_NSIHELPERAPPLAUNCHERDIALOG_NSPRBOOL_ should be undefined. When rebuilding my srpm, this value is correctly undefined (as written in spec file), so at least no error should occur at this point....
A bit clean up. http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/kazehakase.spec http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/kazehakase-0.4.3-4.src.rpm ------------------------------------------------- * Thu Jan 18 2007 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> - 0.4.3-4 - Do not call autoconf, just fix configure. * Sat Dec 23 2006 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> - 0.4.3-3 - Add firefox version dependency for gecko engine --------------------------------------------------
Hello. I'll be happy to review this for you. Full review to come tomorrow...
According to its website, 0.4.4 is released. Would you please update your spec/SRPM accordingly? Thanks.
(In reply to comment #17) > According to its website, 0.4.4 is released. Oh.. 0.4.4 seems to be released yesterday. Thanks. http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/kazehakase.spec http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/kazehakase-0.4.4-1.src.rpm ------------------------------------------------- * Tue Jan 30 2007 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> - 0.4.4-1 - 0.4.4
Sorry to take so long on this one. I've been quite a bit backlogged at work. :( I really appreciate your patience. Soo.... here we go! == Formal Review of kazehakase 0.4.4-1 == GOOD: rpmlint is silent on both the source and binary RPMs. GOOD: The package follows the naming guidelines, and the spec file is named accordingly ("%{name}.spec"). GOOD: BuildRoot is "%{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)", following the packaging guidelines. GOOD: No duplicate BuildRequires are included; and all necessary BuildRequires are listed. GOOD: Included documentation (%doc) is OK. GOOD: Package builds and runs against system copies of installed tools and libraries; and does not include its own local copies thereof. GOOD: Package includes an appropriate .desktop file since it is a graphical application; and desktop-file-install is properly used to install it. A BuildRequires: desktop-file-utils is also present. GOOD: Macros are used instead of harcoded file names, and usage of these macros (including $RPM_BUILD_ROOT) is consistent throughout the spec file. GOOD: Locale files are handled correctly, using %find_lang. GOOD: Package is not relocatable. GOOD: Package includes appropriate code and content; and final directory and file ownership is OK. Configuration files are marked appropriately (%config). GOOD: Package does not own any system files/directories or any files/directories that conflict with another package. GOOD: Package license (GPL) is OK; and a copy of it is included in the package as documentation (%doc COPYING). The License field in the spec file properly reflects this. GOOD: Spec file is legible; and written in American English. GOOD: The source tarball matches that of upstream: $ md5sum SOURCES/kazehakase-0.4.4* 049fd40c238e6838bcdbe14c37cc9051 SOURCES/kazehakase-0.4.4-srpm.tar.gz 049fd40c238e6838bcdbe14c37cc9051 SOURCES/kazehakase-0.4.4-upstream.tar.gz GOOD: The package successfully builds in mock into x86 binary RPMs on both FC6 and devel/FC7. GOOD: No duplicates are listed in the %files section; and its %defattr line is good. GOOD: Package has an appropriate %clean section, which contains simply "rm -rf $RPM_BUILD_ROOT" GOOD: When installed, the application runs well with no apparent segfaults or major bugs. GOOD: Files are converted to UTF-8 encoding properly. GOOD: Package uses %{?_smp_mflags} and honors %optflags compiler flags properly. GOOD: Package contains no libtool archives (*.la files) N/A: No static libraries or rPath exclusions are needed. N/A: Package is not a web application. N/A: No ExcludeArch/ExclusiveArch tweaking is required. N/A: Package installs no shared libraries into the standard $LIBDIR; thus %post/%postun scriplets of /sbin/ldconfig are not needed. N/A: No large (neither in size nor in quantity) documentation is included, thus no -doc subpackage is needed. N/A: No headers, no pkgconfig files, and no static or unsuffixed shared libraries are included. Thus, no -devel subpackage is needed. N/A: Package contains no %description or Summary translations. N/A: Scriplets are not required for this package. ** FIXME: The only potential issue I see I see with this is the following in the %configure output: ------------------- checking for IceConnectionNumber in -lICE... no checking for SmcSaveYourselfDone in -lSM... no checking X11/SM/SMlib.h usability... no checking X11/SM/SMlib.h presence... no checking for X11/SM/SMlib.h... no ------------------- Perusing through the source (kazahakse-0.4.4/src/kz-app.c), it seems that it can optionally build with XSM (X session manager) support, which is probably a desired feature. :) Adding libSM-devel to the BuildRequires enables this. If you fix this, I'll approve the package for importing. Woo!
Thank you for first reviewing!! (In reply to comment #19) > ** FIXME: The only potential issue I see I see with this is the following in the > %configure output: > ------------------- > checking for IceConnectionNumber in -lICE... no > checking for SmcSaveYourselfDone in -lSM... no > checking X11/SM/SMlib.h usability... no > checking X11/SM/SMlib.h presence... no > checking for X11/SM/SMlib.h... no > ------------------- Umm.. Why didn't I notice this? Bad... fixed. And it seems that 0.4.4.1 is released two days ago. http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SPECS/kazehakase.spec http://www.ioa.s.u-tokyo.ac.jp/~mtasaka/dist/extras/development/SRPMS/kazehakase-0.4.4.1-1.src.rpm --------------------------------------------------- * Fri Feb 2 2007 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> - 0.4.4.1-1 - 0.4.4.1 * Fri Feb 2 2007 Mamoru Tasaka <mtasaka.u-tokyo.ac.jp> - 0.4.4-2 - Add more BuildRequires: anthy-devel, libSM-devel
I'm probably overlooking something, but why is anthy-devel needed at build-time? Thanks.
(In reply to comment #21) > I'm probably overlooking something, but why is anthy-devel needed at build-time? > Thanks. Well, I rechecked the build log and I found: -------------------------------- checking for ANTHY... no -------------------------------- This can be turned to yes in current Fedora packages by installing anthy-devel.
(In reply to comment #22) > Well, I rechecked the build log and I found: > -------------------------------- > checking for ANTHY... no > -------------------------------- > This can be turned to yes in current Fedora packages by > installing anthy-devel. Awesome. From this, everything else looks good and this package is APPROVED. :] Please remember to close this bug as NEXTRELEASE after you've imported and built it.
Thank you for reviewing and approving this package!! Well, * Rebuild for FE-devel succeeded. Umm.. this was the first package after ACL system is introduced into cvs system and I was a bit confused, actually... * SyncNeeded requested for FE-6, FE-5 (for FE-5, I have to recheck spec file) Now I close this bug as CLOSED NEXTRELEASE. Thank you. ---------------------------------------------------------- btw, I still meet deluge freeze on FC-devel (not on FC-5) I want to figure out what is the problem, however currently I don't know the way...
Package Change Request ====================== Package Name: kazehakase New Branches: F-8
cvs done.
Package Change Request ====================== Package Name: kazehakase New Branches: F-12 Owners: mtasaka Early branch request.
CVS done.