Spec URL: http://salimma.fedorapeople.org/for_review/web/google-gadgets.spec SRPM URL: http://salimma.fedorapeople.org/for_review/web/google-gadgets-0.9.1-1.fc9.src.rpm Description: Google Gadgets for Linux provides a platform for running desktop gadgets under Linux, catering to the unique needs of Linux users. It is compatible with the gadgets written for Google Desktop for Windows as well as the Universal Gadgets on iGoogle.
Glad to see this! Google Gadgets was featured as the front-page article in the June 12 lwn.net: http://lwn.net/Articles/285099/ I'd add to the description something about this supporting "cross-platform development". "Compatible with" could just mean that it has a common format for data files, but it appears that Google gadgets provides a limited "write once, run everywhere" platform for some kinds of apps.
FYI the newest is 0.9.3.
ping?
Ah yes, will update. I lifted the description mostly from the project page description at the time, it was a bit unpolished. Let's see if the xulrunner backend works properly, now that Fedora-9 has the stable version of xulrunner; it was a bit flaky last month.
Spec URL: http://salimma.fedorapeople.org/for_review/web/google-gadgets.spec SRPM URL: http://salimma.fedorapeople.org/for_review/web/google-gadgets-0.9.3-1.fc9.src.rpm GTK version works well (some gadgets are not compatible with Linux -- the obvious system-related ones, and some that ought to be cross-platform). Qt version has some display issue but also works. I'm currently bundling both and have not included desktop file launchers -- will discuss whether we should have a common library and two subpackage, or keep it intact. In any case, I'll add two desktop launchers, with the GTK one configured to NotShowIn=KDE and the Qt one OnlyShowIn=KDE -- or we can make KDE use the GTK binary and disable the Qt interface for now.
Disabling -qt for now sounds good to me: maybe you can make it a build option for the future?
For 0.9.3-1: * Version - Well, during the time that this bug was assigned to nobody, the upstream version is changed to 0.10.0... Would you upgrade again? * Timestamps - To keep timestamps on installed files, please consider to use: ------------------------------------------------------ make install DESTDIR=$RPM_BUILD_ROOT INSTALL="install -p" CPPROG="cp -p" ------------------------------------------------------ Actually this saves most of the files to be installed - 'INSTALL="install -p"' usually works for recent autotools based Makefiles - And 'CPPROG="cp -p"' usually works for Makefiles using "install-sh" for installation. * Dependency - Please check for -devel subpackage. A. For example, libggadget-dbus-1.0.pc contains the line: ------------------------------------------------------ Requires: libggadget-1.0 dbus-1 ------------------------------------------------------ This means -devel subpackage should have "Requires: dbus-devel" B. Another example is that %_includedir/google-gadgets/ggadget/gtk/tooltip.h contains: ------------------------------------------------------ 19 20 #include <gtk/gtk.h> 21 ------------------------------------------------------ This means that -devel subpackage should have "Requires: gtk2-devel". Then: (In reply to comment #6) > Disabling -qt for now sounds good to me: maybe you can make it a build option > for the future? I feel that enabling qt side does not seem to be bad, however would you tell us your opinion?
I might be able to get a 0.10 SRPM tomorrow -- there are some compilation issues with it. Will go ahead and split the frontends out, but I'll just keep a single -devel package (developers can bite the hard drive space bullet!)
ping again?
Again ping?
I did another spec file wich create 3 packages: - google-gadgets - google-gadget-gtk - google-gadget-qt My troubles appears with mock to compile on i386 (works great in x86-64). I will give you my src.rpm tomorrow. Maybe a merge between our 2 specs cool be fine.
Michel, I will once close this bug if no response is received from you within ONE WEEK.
Sorry about that. Didn't have a chance to look at the problems with 0.10.0, which is still present in 0.10.1 but, as it turns out, just requires using LD_LIBRARY_PATH during the build process. http://salimma.fedorapeople.org/for_review/web/google-gadgets-0.10.1-1.fc10.src.rpm http://salimma.fedorapeople.org/for_review/web/google-gadgets.spec UI split into -gtk and -qt subpackages, both providing -frontend which the base package depends on. The GTK interface is more mature at this point -- the Qt interface does not seem to provide a working dock.
Umm... doesn't build on dist-f10: http://koji.fedoraproject.org/koji/taskinfo?taskID=785923 By the way you can check if your srpm can be rebuilt correctly using koji like: $ koji build --scratch <target> <srpm_you_want_to_try> where <target> can be dist-f10, dist-f9-updates-candidate or dist-f8-updates-candidate (and some olpc related target). When the rebuild succeeds, the result binary rpms and some logs are put under http://koji.fedoraproject.org/scratch/<your_FAS_name>/task_<task_id>/
There were some missing build requirements, sorry. Should have tried a scratch build. http://koji.fedoraproject.org/koji/taskinfo?taskID=787490 http://salimma.fedorapeople.org/for_review/web/google-gadgets-0.10.1-2.fc10.src.rpm http://salimma.fedorapeople.org/for_review/web/google-gadgets.spec
Will review tomorrow.
For 0.10.1-2: * About rpath/linking issue --------------------------------------------------------------------- sed -i 's|^hardcode_libdir_flag_spec=.*|hardcode_libdir_flag_spec=""|g' libtool sed -i 's|^runpath_var=LD_RUN_PATH|runpath_var=DIE_RPATH_DIE|g' libtool # Set LD_LIBRARY_PATH: desktop file creation requires access to the libraries # which have not been installed export LD_LIBRARY_PATH=`pwd`/ggadget/.libs --------------------------------------------------------------------- - Well, actually the reason you have to set LD_LIBRARY_PATH temporarily is that you killed rpath completely even on build stage under builddir by the two lines above. Usually removing rpath by this way just "breaks" libtool and especially when the package has its own library path (like %_libdir/%name or so) linking fails like this way. The reason this package adds standard rpath is - When linking libtool tries to find out standard libraries only from /usr/lib and /lib, so on 64 bits architectures the unsearched /usr/lib64 or so is added as rpath. (Fedora libtool on 64 bits actually searches libraries also from /usr/lib64 and so on. You can check this by the diff of %_bindir/libtool (this is bash script) on i386 and x86_64 archs) Note that libtool is created from configure - hosts/*/Makefile.in has unneeded -R$(libdir) :( So I recommend: ---------------------------------------------------------------------- %prep %setup -q -n %{name}-for-linux-%{version} # Permission fixes chmod -x ggadget/qt/utilities.h # Rpath issue # Add library search path sed -i.libdir_syssearch -e \ '/sys_lib_dlsearch_path_spec/s|/usr/lib |/usr/lib /usr/lib64 /lib /lib64 |' \ configure # No!! No!! sed -i.extra_R -e \ 's|-R\$(libdir)||' \ hosts/*/Makefile.in ---------------------------------------------------------------------- * Timestamp issue - As said above, would you consider to use the following? ---------------------------------------------------------------------- make install DESTDIR=$RPM_BUILD_ROOT \ INSTALL="install -p" CPPROG="cp -p" ----------------------------------------------------------------------
Thanks! And yes, I forgot about timestamps; fixed in latest build. http://koji.fedoraproject.org/koji/taskinfo?taskID=790922 http://salimma.fedorapeople.org/for_review/web/google-gadgets-0.10.1-3.fc10.src.rpm http://salimma.fedorapeople.org/for_review/web/google-gadgets.spec
Okay. ---------------------------------------------------------------------- This package (google-gadgets) is APPROVED by mtasaka ----------------------------------------------------------------------
Thanks. New Package CVS Request ======================= Package Name: google-gadgets Short Description: Google Gadgets for Linux Owners: salimma Branches: F-9 InitialCC:
cvs done.
google-gadgets-0.10.1-3.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/google-gadgets-0.10.1-3.fc9
Thanks. Now closing.
google-gadgets-0.10.1-4.fc9 has been submitted as an update for Fedora 9. http://admin.fedoraproject.org/updates/google-gadgets-0.10.1-4.fc9
google-gadgets-0.10.1-4.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.