Spec URL: http://uggla.free.fr/rpmbuild/SPECS/gwaei.spec SRPM URL: http://uggla.free.fr/rpmbuild/SRPMS/gwaei-1.2.1-4.fc12.src.rpm Description: This is my first package, and I'm looking for a sponsor. gWaei is an easy to use and yet powerful full-featured dictionary program for Japanese to English translation. It organizes results by relevance, supports regex searches, tabs, spell checking, kanji handwriting recognition and an accompanying console version for searches through the terminal. The dictionary files it uses are from Jim Breen's WWWJDIC project and are installed separately through the program.
Sorry, Just I just forget to mention the rpmlint output : [ctb@uggla SRPMS]$ rpmlint gwaei-1.2.1-4.fc12.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [ctb@uggla x86_64]$ rpmlint gwaei-1.2.1-4.fc12.x86_64.rpm gwaei.x86_64: W: conffile-without-noreplace-flag /etc/gconf/schemas/gwaei.schemas 1 packages and 0 specfiles checked; 0 errors, 1 warnings. Mock is fine for i386 as well as x86_64. I don't put the output on this thread feel free to tell if if required. I made a build test with Koji, it looks fine for all architecture. Output here : https://koji.fedoraproject.org/koji/taskinfo?taskID=1983466 Best regards. René
Well, I want to go to bed for now, however some brief notes: - On rawhide your package does not build as below. http://koji.fedoraproject.org/koji/taskinfo?taskID=1983436 This is because Fedora 13 changed the behavior of linker: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange To check F-13 linker behavior on F-12/11, you can do this by adding ------------------------------------------------------------- export LDFLAGS="-Wl,--no-add-needed" ------------------------------------------------------------- before %configure line. Then some other notes - "Requires: cjkuni-ukai-fonts" is not desired. On Fedora cjkuni-XXXX is the default font for Chinese but not for Japanese. On Fedora Japanese people use "vlgothic-fonts" rpm for fonts by default. - Your spec file contains: ------------------------------------------------------------- #%configure --disable-schemas %configure --disable-schemas-install ------------------------------------------------------------- With this build log will show (actually https://koji.fedoraproject.org/koji/taskinfo?taskID=1983466 shows) that configure is executed twice, not once. This is because rpmbuild will expand macros (in this case %configure) anyway even if the line is marked as a comment. To prevent this, you should use #%%configure so that macros won't be expanded in comment lines. - Please consider to use ------------------------------------------------------------- make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p" ------------------------------------------------------------- to keep timestamps on installed files as much as possible. This method usually works for Makefiles generated by recent autotools. - Currently documents are installed both under - /usr/share/doc/gwaei - /usr/shaer/doc/gwaei-1.2.1 Please unify these directories. - I have not checked this package in details, however usually the file "ABOUT-NLS" is unuseful. - Files/directories under %{_datadir}/doc/ are automatically marked as %doc. - rpmlint may complain, however we usually don't regard gconf schemas files as config files so please remove %config from gconf schemas file.
Hello Mamoru and all, First I would like to thank you for this first review and all the advises provided. I have made the required corrections, you will find the new files here : Spec URL: http://uggla.free.fr/rpmbuild/SPECS/gwaei.spec SRPM URL: http://uggla.free.fr/rpmbuild/SRPMS/gwaei-1.2.1-5.fc12.src.rpm RPMLINT output : [ctb@uggla SRPMS]$ rpmlint gwaei-1.2.1-5.fc12.src.rpm 1 packages and 0 specfiles checked; 0 errors, 0 warnings. [ctb@uggla x86_64]$ rpmlint gwaei-1.2.1-5.fc12.x86_64.rpm gwaei.x86_64: W: non-conffile-in-etc /etc/gconf/schemas/gwaei.schemas 1 packages and 0 specfiles checked; 0 errors, 1 warnings. Regarding your comment about rpmlint, despite the warning, I think this is ok. KOJI output : I have built the package with koji on all architectures for F12 and rawhide. You can look at the F12 result here : https://koji.fedoraproject.org/koji/taskinfo?taskID=1999701 and F13 here : https://koji.fedoraproject.org/koji/taskinfo?taskID=1999721 Waiting for your feedbacks. Best regards. René
Created attachment 395148 [details] gdb log Well, before I proceed to review this: For me gwaei easily segfaults with - once $ rm -rf ~/.waei - execute $ gwaei - choose "Install Dictionaries", click "Add" on "English:" gdb log attached. Note that #2 0x0806d21a in install_thread (dictionary=0x0) at settings-callbacks-gtk.c:227 is apparently bad.
Created attachment 395176 [details] Gwaei screenshot.
Hello Mamoru, I have not fully checked the gdb log file for the moment. I quickly tried what you did but I can not manage to reproduce the bug on my side. I tried to check with my locale (fr) and Japanese locale this is the same, gwaei is working fine no segfault. As you can see with this screenshot : https://bugzilla.redhat.com/attachment.cgi?id=395176, the download is in progress. However, there is a main difference, you are using F13 and I'm using F12. I'm gonna try to : - look deeper in the gdb log you provided and send it also to upstream. - install rawhide on a vm to check if I can reproduce the bug. Best regards. René
Created attachment 395349 [details] gdb log with setting G_DEBUG=fatal_criticals Well, I don't see what you attached. Before gwaei starts to download dictonaries, gwaei segfaults. After some quick investigation, G_MODULE_EXPORT void do_dictionary_install() in src/settings-callbacks-gtk.c shows: ------------------------------------------------------------ 467 G_MODULE_EXPORT void do_dictionary_install (GtkWidget *widget, gpointer data) 468 { 469 //Make sure the files are clean 470 do_dictionary_remove(widget, data); 471 472 //Create the name string 473 char name[100]; 474 gw_parse_widget_name(name, widget, TRUE); ------------------------------------------------------------ With this it seems that "name" should be a string like "Kanji" or "English" or so, while on my system name is "'tkButton". Perhaps related to this, when trying to doing the action written in comment 4, I see some warnings like: ------------------------------------------------------------- (gwaei:30494): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_label_set_text: assertion `GTK_IS_LABEL (label)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_widget_hide: assertion `GTK_IS_WIDGET (widget)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_widget_show: assertion `GTK_IS_WIDGET (widget)' failed (gwaei:30494): Gtk-CRITICAL **: gtk_widget_set_sensitive: assertion `GTK_IS_WIDGET (widget)' failed ------------------------------------------------------------- So I set "G_DEBUG=fatal_criticals" and tried the process in my comment 4, then gwaei segfaults as attached. It seems that there is some serious mishandling of GTK widgets in gwaei, however I am not familiar with this area.
Hi guys. The warnings are not just a minor thing. They are why the code dies when it looks for a string on something that isn:t there. In Glade I assigned all the elements in settings.ui with names like english_remove_button, kanji_install_button etc. If the objects arent there, there is no string to pull from which is probably causing a buffer overflow or some other pointer error. The first question is is settings.ui being installed correctly? Is it loading? Is this gtk 2.18? Around gWaei 1.2.0 I make some dictionary management code which I am planning to rewrite the dictionary installer to use which will make the code more straight forward. But that is probably for the next version. Also, is there a LiveCD for Fedora 13 out yet? I have tried emulating Fedora in qemu, but it was unusuable. Cheers, Zach
Hello, Zachary: (In reply to comment #8) > The first question is is settings.ui being installed correctly? - There is /usr/share/gwaei/settings.ui > Is it loading? - How can I check is setting.ui is loaded correctly? > Is this gtk 2.18? - I am using gtk2-2.19.5-1.fc13.i686 . F-12 uses gtk2-2.18.6-3.fc12 > Also, is there a LiveCD for Fedora 13 out yet? I have tried emulating Fedora > in qemu, but it was unusuable. - Well currently I guess we have to create this by ourselves with reading http://fedoraproject.org/wiki/FedoraLiveCD/LiveCDHowTo
Any news on this package?
(In reply to comment #10) > Any news on this package? Hello Mamoru, I spent some time last week looking at the issue. I have just provided my latest findings to Zachary. In short, it looks like there is something wrong between the *.ui files generated with glade and gtk 2.19.6 provided by F13. These files should be interpreted by "Gtkbuilder" to build the required widgets correctly, but this appears to not be the case. Gtk 2.18.6 (gtk stable rel included in F12) is working correctly. So according to me, we may face an issue with either gtk or incompatible .ui files created by glade. I think that this will require more investigations and probably bug reports to these projects. Regarding the package, I would like to know your opinion. I perfectly understand that the best option is to correct the bug but the idea will be to provide gwaei for F12 users and in parallel debug gwaei for F13. So to go ahead, is it mandatory to fix the bug with F13 right now as the application is working fine with F12 ? Maybe I could make an explicit requirement to gtk 2.18.6 for F13, do you think that this could be a acceptable solution ? Best regards. René.
It may have something to do with how gtk2.19 separates the gtkentry into 2 separate objects too. The GtkEntryBuffer object is brand new. http://library.gnome.org/devel/gtk/unstable/GtkEntry.html#gtk-entry-new-with-buffer
(In reply to comment #11) > So to go ahead, is it mandatory to fix the bug with F13 right now as the > application is working fine with F12 ? I don't think there is a strong reason why we should rush to import this package into F-12 when it is apparent that this package won't work on F-13. Also anyway this package needs fixing for newer gtk. > Maybe I could make an explicit requirement to gtk 2.18.6 for F13, do you think > that this could be a acceptable solution ? It cannot be done. There is no guarantee that other packages built with newer gtk work with older gtk.
(In reply to comment #13) > (In reply to comment #11) > > So to go ahead, is it mandatory to fix the bug with F13 right now as the > > application is working fine with F12 ? > I don't think there is a strong reason why we should rush > to import this package into F-12 when it is apparent that this > package won't work on F-13. Also anyway this package needs fixing for > newer gtk. > > Maybe I could make an explicit requirement to gtk 2.18.6 for F13, do you think > > that this could be a acceptable solution ? > It cannot be done. There is no guarantee that other packages built > with newer gtk work with older gtk. Yes, this will likely become an issue for other distros, too. If I fix the xml file manually, I fear that glade will break it again, so I believe the only choice is to move that specific ui code out into C. On a side note, looks like gconf was suddenly labeled depricated for gsettings with 2.19. Looks like Gnome 3.0 is still a moving target.
I believe the major issues should be fixed. It looks like the gtk+-2.19.6 guys suddenly decided that gtk_widget_set_name () didn't need to be set for gtkbuilder objects. I am not sure I caught everything yet because I haven't been able to get the Fedora 12 LiveCD to even boot. In any case, anyone want to do some basic testing while I try to sort this out? The git code for 1.3.0 should at least be of beta quality now. Download from here -> http://sourceforge.net/projects/gwaei/develop If things don't seem to bad in Fedora 13, I will be pushing forward for a gWaei release in the next few days.
Well I tried latest git trunk and while I see some issues at least segv I obserbed does not seem to be reproducible now and directories are correctly downloaded.
It took me 3-4 install attempts and 4-6 hours to get Fedora 13 properly installed. That was a monster. At least I can test locally now. I appreciate the testing, Mamoru. I was tweaking the git code until about the 19th using info from bug testers. I did the official 1.3.0 release today, on the 20th of March. I'll be prepping for a 1.3.1 in due time depending on what comes my way. I just have to convert the menus and the buttons for the radical search tool to C from xml to get myself out of the glade/gtkbuilder buggy hell. Should be a good target for 1.4.0.
Hello Mamoru and all, I have rebuilt the package for gwaei 1.3.0 release. Zachary did a great job and now the application works with F13 as you already noticed. Spec URL: http://uggla.free.fr/rpmbuild/SPECS/gwaei.spec SRPM URL: http://uggla.free.fr/rpmbuild/SRPMS/12/gwaei-1.3.0-1.fc12.src.rpm RPMLINT output : ---------------- [ctb@uggla x86_64]$ rpmlint gwaei-1.3.0-1.fc12.x86_64.rpm gwaei.x86_64: W: spelling-error %description -l en_US kanji -> Kantian, Kanpur, Kansas gwaei.x86_64: W: non-conffile-in-etc /etc/gconf/schemas/gwaei.schemas 1 packages and 0 specfiles checked; 0 errors, 2 warnings. [ctb@uggla SRPMS]$ rpmlint gwaei-1.3.0-1.fc12.src.rpm gwaei.src: W: spelling-error %description -l en_US kanji -> Kantian, Kanpur, Kansas 1 packages and 0 specfiles checked; 0 errors, 1 warnings. KOJI output : ------------- I have built the package with koji on all architectures for F12, F13 and rawhide. You can look at the F12 result here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2066774 F13 here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2066779 and F14 here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2066782 Waiting for your feedbacks. Best regards. René
Well, for 1.3.0-1 * SourceURL - For sourceforge hosted tarball, please follow https://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net * BR - Check if "BR: gettext-devel" is really needed. * autotool called automatically - build.log shows: ----------------------------------------------------------------- 44 + ./configure --build=i386-redhat-linux-gnu --host=i386-redhat-linux-gnu --program-prefix= --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-schemas-install 125 + make -j4 603 Making all in help 604 make[2]: Entering directory `/builddir/build/BUILD/gwaei-1.3.0/help' 605 cd .. && /bin/sh /builddir/build/BUILD/gwaei-1.3.0/missing --run automake-1.10 --gnu help/Makefile 606 /builddir/build/BUILD/gwaei-1.3.0/missing: line 54: automake-1.10: command not found 607 WARNING: `automake-1.10' is missing on your system. You should only need it if 608 you modified `Makefile.am', `acinclude.m4' or `configure.ac'. 609 You might want to install the `Automake' and `Perl' packages. 610 Grab them from any GNU archive site. 611 cd .. && /bin/sh ./config.status help/Makefile 612 config.status: creating help/Makefile ----------------------------------------------------------------- Here automake is called after configure/make. autotools should be already executed before configure and automatical call of autotools should be avoided. Usually timestamps on some files are wrong (or maybe autotools were not called correctly before the tarball was packaged). Please fix this. * Scriptlets - GConf2 scriptlets are updated (changed): https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#GConf ! Note "BuildRequires: GConf2" is needed to make use of %gconf related macros - GTK related scriptlets has some mistakes ( note that there is no %preun scriptlets for GTK cache, instead some scriptlets are %postun scriptlets ) https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Icon_Cache * Documents - We install document files under %_defaultdocdir/%name-%version, so please consider to move document files to this directory - Also installing "AUTHORS" file is recommended. - Files / directories under %_defaultdocdir are automatically marked as %doc.
(In reply to comment #19) Hello Mamoru, Thanks for the previous review. I have made a new package hoping it will correct all previous pitfalls. Please look at my comments below : > Well, for 1.3.0-1 > > * SourceURL > - For sourceforge hosted tarball, please follow > https://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net Gwaei binary package URL is : http://downloads.sourceforge.net/project/gwaei/gwaei/1.3.0/gwaei-1.3.0.tar.gz As you can see upstream doesn't respect Fedora' spec : http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz for any reason. So I have kept the real link inside the spec file. Should I request a change upstream to fix this ? > > * BR > - Check if "BR: gettext-devel" is really needed. > Yes it is required by automake. > * autotool called automatically > - build.log shows: > ----------------------------------------------------------------- > 44 + ./configure --build=i386-redhat-linux-gnu > --host=i386-redhat-linux-gnu --program-prefix= --disable-dependency-tracking > --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin > --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include > --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var > --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info > --disable-schemas-install > 125 + make -j4 > 603 Making all in help > 604 make[2]: Entering directory `/builddir/build/BUILD/gwaei-1.3.0/help' > 605 cd .. && /bin/sh /builddir/build/BUILD/gwaei-1.3.0/missing --run > automake-1.10 --gnu help/Makefile > 606 /builddir/build/BUILD/gwaei-1.3.0/missing: line 54: automake-1.10: > command not found > 607 WARNING: `automake-1.10' is missing on your system. You should only > need it if > 608 you modified `Makefile.am', `acinclude.m4' or `configure.ac'. > 609 You might want to install the `Automake' and `Perl' packages. > 610 Grab them from any GNU archive site. > 611 cd .. && /bin/sh ./config.status help/Makefile > 612 config.status: creating help/Makefile > ----------------------------------------------------------------- > Here automake is called after configure/make. autotools should be > already executed before configure and automatical call of > autotools should be avoided. > Usually timestamps on some files are wrong (or maybe autotools > were not called correctly before the tarball was packaged). > Please fix this. > I have fixed this adding autogen.sh (coming from gwaei's git) that will do the required aclocal, auto* ... commands. Although, the warning you mentioned disappeared, I'm not sure this is the best way to do it. Advices on this point are welcomed. > * Scriptlets > - GConf2 scriptlets are updated (changed): > https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#GConf > ! Note > "BuildRequires: GConf2" is needed to make use of %gconf related > macros > Thanks for the notification, I didn't realized it changed. Fix done. > - GTK related scriptlets has some mistakes > ( note that there is no %preun scriptlets for GTK cache, instead > some scriptlets are %postun scriptlets ) > https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Icon_Cache > Fix done too. > * Documents > - We install document files under %_defaultdocdir/%name-%version, > so please consider to move document files to this directory > - Also installing "AUTHORS" file is recommended. > - Files / directories under %_defaultdocdir are automatically marked > as %doc. Unified into /usr/share/doc/gwaei-1.3.0 I have added AUTHORS and THANKS files. You will be able to find the new package here : Spec URL: http://uggla.free.fr/rpmbuild/SPECS/gwaei.spec SRPM URL: http://uggla.free.fr/rpmbuild/SRPMS/12/gwaei-1.3.0-2.fc12.src.rpm RPMLINT output : ---------------- [ctb@uggla x86_64]$ rpmlint gwaei-1.3.0-2.fc12.x86_64.rpm gwaei.x86_64: W: spelling-error %description -l en_US kanji -> Kantian, Kanpur, Kansas gwaei.x86_64: W: non-conffile-in-etc /etc/gconf/schemas/gwaei.schemas gwaei.x86_64: W: dangerous-command-in-%pre rm gwaei.x86_64: W: dangerous-command-in-%post rm 1 packages and 0 specfiles checked; 0 errors, 4 warnings. [ctb@uggla SRPMS]$ rpmlint gwaei-1.3.0-2.fc12.src.rpm gwaei.src: W: spelling-error %description -l en_US kanji -> Kantian, Kanpur, Kansas 1 packages and 0 specfiles checked; 0 errors, 1 warnings. KOJI output : ------------- I have built the package with koji on all architectures for F12, F13 and rawhide. You can look at the F12 result here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2079390 F13 here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2079399 and F14 here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2079410 Waiting for your feedbacks. Best regards. René
Created attachment 403340 [details] Patch to kill autotool call for help/Makefile.am For -2: * SourceURL (In reply to comment #20) > (In reply to comment #19) > > - For sourceforge hosted tarball, please follow > > https://fedoraproject.org/wiki/Packaging/SourceURL#Sourceforge.net > As you can see upstream doesn't respect Fedora' spec : > http://downloads.sourceforge.net/%{name}/%{name}-%{version}.tar.gz > for any reason. ---------------------------------------------------------------- $ env LANG=C wget -N http://downloads.sourceforge.net/gwaei/gwaei-1.3.0.tar.gz --2010-03-30 01:15:34-- http://downloads.sourceforge.net/gwaei/gwaei-1.3.0.tar.gz Resolving downloads.sourceforge.net... 216.34.181.59 Connecting to downloads.sourceforge.net|216.34.181.59|:80... connected. HTTP request sent, awaiting response... 302 Found Location: http://jaist.dl.sourceforge.net/project/gwaei/gwaei/1.3.0/gwaei-1.3.0.tar.gz [following] --2010-03-30 01:15:34-- http://jaist.dl.sourceforge.net/project/gwaei/gwaei/1.3.0/gwaei-1.3.0.tar.gz Resolving jaist.dl.sourceforge.net... 150.65.7.130 Connecting to jaist.dl.sourceforge.net|150.65.7.130|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 675297 (659K) [application/x-gzip] Saving to: `gwaei-1.3.0.tar.gz' 100%[====================================================================================================>] 675,297 --.-K/s in 0.1s 2010-03-30 01:15:34 (6.20 MB/s) - `gwaei-1.3.0.tar.gz' saved [675297/675297] ---------------------------------------------------------------- - So the URL recommended by Fedora seems to be working. * autogen.sh - If this is needed, it is more readable to add autogen.sh as SourceX and copy it to build directory, rather than to create a patch which generates autogen.sh. - It is recommended to call autogen.sh in %prep, rather than in %build. * automated autotool call > > * autotool called automatically > > Here automake is called after configure/make. autotools should be > > already executed before configure and automatical call of > > autotools should be avoided. > > Usually timestamps on some files are wrong (or maybe autotools > > were not called correctly before the tarball was packaged). > > Please fix this. > > I have fixed this adding autogen.sh (coming from gwaei's git) that will do the > required aclocal, auto* ... commands. > > Although, the warning you mentioned disappeared, I'm not sure this is the best > way to do it. Advices on this point are welcomed. - Still aututools are called automatically: http://koji.fedoraproject.org/koji/taskinfo?taskID=2081887 --------------------------------------------------------------------- 326 + make -j4 327 (CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /builddir/build/BUILD/gwaei-1.3.0/missing --run autoheader) 328 rm -f stamp-h1 329 touch config.h.in 809 Making all in help 810 make[2]: Entering directory `/builddir/build/BUILD/gwaei-1.3.0/help' 811 cd .. && /bin/sh /builddir/build/BUILD/gwaei-1.3.0/missing --run automake-1.11 --gnu help/Makefile 1003 cd .. && /bin/sh ./config.status help/Makefile 1004 config.status: creating help/Makefile --------------------------------------------------------------------- So config.h.in and help/Makefile.am or so are not correctly updated. ! After some investigation: The first one (autoheader being called to regenerate config.h.in) is while autogen.sh reads: --------------------------------------------------------------------- 1 #! /bin/sh 2 3 aclocal \ 4 && gnome-doc-prepare -c -f \ 5 && automake -c -f --add-missing \ 6 && autoconf -f --------------------------------------------------------------------- Actually: --------------------------------------------------------------------- $ gnome-doc-prepare -c -f Remember to add 'GNOME_DOC_INIT' to configure.ac. You should update your 'aclocal.m4' by running aclocal. Putting files in AC_CONFIG_MACRO_DIR, 'm4'. --------------------------------------------------------------------- So aclocal should be called after gnome-doc-prepare. Also "autoheader -f " is actually not called before configure. So calling "autoheader -f" should be added to autogen.sh The latter one (automake being automatically called to regenerate help/Makefile.in) is due to incorrect handling of help/Makefile.am in configure.ac. configure.ac contains: --------------------------------------------------------------------- 133 if([test x$gnome = xfalse]);then([cp help/Makefile.am.gnome help/Makefile.am]);fi 134 if([test x$gnome = xtrue]);then([cp help/Makefile.am.none help/Makefile.am]);fi --------------------------------------------------------------------- This makes help/Makefile.am renewed during configure process. So after configure finished, Makefile.in has to be regenerated from renewed help/Makefile.am and autotools are recalled. So gnome/non-gnome handling in configure.ac|help/Makefile.am must be fixed. The attached patch will fix this issue.
(In reply to comment #21) Hello Mamoru, Thanks again for this new review. I have made a new package. Please look at my comments below : > * SourceURL > > ... > - So the URL recommended by Fedora seems to be working. You are right. I apologize because I didn't think that a link could exist. > * autogen.sh > - If this is needed, it is more readable to add autogen.sh as SourceX > and copy it to build directory, rather than to create a patch which > generates autogen.sh. > - It is recommended to call autogen.sh in %prep, rather than in %build. Done. > > * automated autotool call > >... I have modified autogen.sh with all your advises and inserted your patch. You will be able to find the new package here : Spec URL: http://uggla.free.fr/rpmbuild/SPECS/gwaei.spec SRPM URL: http://uggla.free.fr/rpmbuild/SRPMS/12/gwaei-1.3.0-3.fc12.src.rpm RPMLINT output : ---------------- [ctb@uggla x86_64]$ rpmlint gwaei-1.3.0-3.fc12.x86_64.rpm gwaei.x86_64: W: spelling-error %description -l en_US kanji -> Kantian, Kanpur, Kansas gwaei.x86_64: W: non-conffile-in-etc /etc/gconf/schemas/gwaei.schemas gwaei.x86_64: W: dangerous-command-in-%pre rm gwaei.x86_64: W: dangerous-command-in-%post rm 1 packages and 0 specfiles checked; 0 errors, 4 warnings. [ctb@uggla SRPMS]$ rpmlint gwaei-1.3.0-3.fc12.src.rpm gwaei.src: W: spelling-error %description -l en_US kanji -> Kantian, Kanpur, Kansas 1 packages and 0 specfiles checked; 0 errors, 1 warnings. KOJI output : ------------- I have built the package with koji on all architectures for F12, F13 and rawhide. You can look at the F12 result here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2094487 F13 here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2094502 and F14 here : http://koji.fedoraproject.org/koji/taskinfo?taskID=2094512 Waiting for your feedbacks. Best regards. René
Okay. - "BR: gettext" is not needed because "BR: gettext-devel" also exists and gettext-devel pulls gettext in. Now * This package can be approved now * I saw your another review request (bug 579369) very quickly, and it looks good at first glance (however for font related packages I hope someone else will want to review them) --------------------------------------------------------------- This package (gwaei) is APPROVED by mtasaka --------------------------------------------------------------- Please follow the procedure written on: http://fedoraproject.org/wiki/PackageMaintainers/Join from "Install the Client Tools (Koji)" Now I am sponsoring you. If you want to import this package into Fedora 11/12/13, you also have to look at http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem/Bodhi-info-DRAFT (after once you rebuilt this package on koji Fedora rebuilding system). If you have questions, please ask me. Removing NEEDSPONSOR.
Hello Mamoru, Thanks for your sponsoring and also the help you provided to me. I have learned a lot with this first package and all the advises provided. I'm gonna go ahead with the following process steps. Of course as proposed, I will ask you questions if required. Cheers, René
New Package CVS Request ======================= Package Name: gwaei Short Description: A Japanese dictionary for Gnome Owners: uggla Branches: F12 F13 InitialCC: mtasaka
CVS done (by process-cvs-requests.py).
gwaei-1.3.0-3.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/gwaei-1.3.0-3.fc13
gwaei-1.3.0-3.fc12 has been submitted as an update for Fedora 12. http://admin.fedoraproject.org/updates/gwaei-1.3.0-3.fc12
gwaei-1.3.0-3.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update gwaei'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/gwaei-1.3.0-3.fc13
Closing.
gwaei-1.3.0-3.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
gwaei-1.3.0-3.fc12 has been pushed to the Fedora 12 stable repository. If problems still persist, please make note of it in this bug report.
Package Change Request ====================== Package Name: gwaei New Branches: F14 EL6 Owners: uggla
Git done (by process-git-requests). There is already a f14 branch, so only did the EL-6 one.