http://freshmeat.net/projects/fyre/ Reproducible: Always Steps to Reproduce: 1. 2. 3. Fyre provides a rendering system for chaotic maps, with an interactive GTK+ frontend and the ability to create high-resolution images from the command line.
Created attachment 36098 [details] fyre-0.6.ebuild
Created attachment 36099 [details, diff] fyre-0.6.gentoo.diff Cheers
Thank you.. :)
don't you wanna see this in portage tree ?
I've been meaning to ask him why he closed it... Thanks Martin
Oh, sorry, this was my first bug-report and i didn't know that i should request the addition to the portage tree here, too. Sure i wanna see it there. So, eer, I don't really know what to do now. Write a new bug report? Change the title of this one? Or are the neccesary steps to add it already done? Regards, Ren
Oh, sorry, this was my first bug-report and i didn't know that i should request the addition to the portage tree here, too. Sure i wanna see it there. So, eer, I don't really know what to do now. Write a new bug report? Change the title of this one? Or are the neccesary steps to add it already done? Regards, René
No need for a new bug. That's why this one was reopened. All you can do is wait, really. If a dev thinks it's worthy (and has spare time) then it will get committed. Cheers
*** Bug 47901 has been marked as a duplicate of this bug. ***
Created attachment 47545 [details] tweak deps, add USE flags, install initscript, update for 0.7 I'm posting the whole ebuild instead of a patch because the patch is actually larger than the new file. (54 vs. 49 lines) This adds four USE flags: * binreloc -- relocatable binaries? (configure option; looks useful. Not sure what it does) * binreloc-threads -- same thing * openexr -- support for media-libs/openexr * gnet -- Use net-libs/gnet for network communication (perhaps this should be `network' instead?) It also moves the initscript provided in the tarball (in the contrib/ directory) someplace appropriate. Also, fyre 0.7 uses auto*, and no longer applies cleanly against the CFLAGS-related patch. However, the configure script overrides CFLAGS and CXXFLAGS, and it looks like it might be deliberate... Should we ask the developer?
Big oops, that ebuild doesn't work. roothorick@prodigy ~ $ fyre (fyre:3233): libglade-WARNING **: could not find glade file 'data/explorer.glade' (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 509 (glade_xml_get_widget): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 402 (glade_xml_signal_connect_full): assertion `self != NULL' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 509 (glade_xml_get_widget): assertion `self != NULL' failed (fyre:3233): Gtk-CRITICAL **: file gtkwidget.c: line 4206 (gtk_widget_set_sensitive): assertion `GTK_IS_WIDGET (widget)' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 509 (glade_xml_get_widget): assertion `self != NULL' failed (fyre:3233): Gtk-CRITICAL **: file gtkstatusbar.c: line 268 (gtk_statusbar_get_context_id): assertion `GTK_IS_STATUSBAR (statusbar)' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 509 (glade_xml_get_widget): assertion `self != NULL' failed (fyre:3233): Gtk-CRITICAL **: file gtkbox.c: line 372 (gtk_box_pack_start): assertion `GTK_IS_BOX (box)' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 509 (glade_xml_get_widget): assertion `self != NULL' failed (fyre:3233): Gtk-CRITICAL **: file gtkcontainer.c: line 948 (gtk_container_add): assertion `GTK_IS_CONTAINER (container)' failed (fyre:3233): libglade-CRITICAL **: file glade-xml.c: line 509 (glade_xml_get_widget): assertion `self != NULL' failed (fyre:3233): Gtk-CRITICAL **: file gtkrange.c: line 450 (gtk_range_get_adjustment): assertion `GTK_IS_RANGE (range)' failed Segmentation fault Local testing suggests it is hardcoded to the prefix given to the configure script (running binary out of source directory doesn't work, running it out of test prefix in home directory does)... this will be fun.
My suggestions: - Things might work better if you turned on binreloc, since that's how it knows where to find the data files. turning it off is really only useful if you're not installing to a prefix. - I would suggest renaming the 'gnet' use to 'cluster' or somesuch, since it's not as likely that the user wants gnet support so much as cluster rendering. - The CFLAGS additions that the configure script uses are indeed deliberate. -O3 and -ffast-math make significant speed differences on every platform, and -D__NO_INLINES__ helps on intel (and possibly others). Good luck!
failed to compile, media-libs/openexr-1.0.7 net-libs/gnet-2.0.5 fyre-0.7.ebuild gcc -DHAVE_CONFIG_H -I. -I. -I.. -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/libglade-2.0 -I/usr/include/libxml2 -I/usr/local/include/OpenEXR -pthread -I/usr/include/gnet-2.0 -I/usr/lib/gnet-2.0/include/ -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include '-DFYRE_DATADIR="data"' -O2 -march=athlon-xp -fomit-frame-pointer -pipe -D__NO_INLINE__ -Wall -O3 -ffast-math -c `test -f remote-client.c || echo './'`remote-client.c exr.cpp:138: error: `file' undeclared (first use this function) make[2]: *** [exr.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/fyre-0.7/work/fyre-0.7/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/fyre-0.7/work/fyre-0.7' make: *** [all] Error 2 !!! ERROR: media-gfx/fyre-0.7 failed. !!! Function src_compile, Line 40, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message.
Roman Frolow: It looks like you have a bad pkgconfig file somewhere, your include path for OpenEXR is in /usr/local and I doubt that's where the ebuild for openexr installs to.
Created attachment 51090 [details] Ebuild for Fyre 0.9 Here's an ebuild and some patches to Fyre 0.9. Untar this into your local portage tree and enjoy. For anyone who's having trouble building Fyre with OpenEXR, there seems to be a bug in the latest stable install (1.0.7) whereby a wrong path is put into /usr/lib/pkgconfig/OpenEXR.pc. Just edit the file and change "prefix=/usr/local" to "prefix=/usr" and all should be well.
Created attachment 51108 [details] Ebuild for Fyre 0.9 (fixed binreloc, renamed exr->openexr) This is just a minor tweak to Cory's ebuild: - binreloc is always now always enabled. Fyre 0.9 can't reliably find its datadir without binreloc, and autodetection won't work inside the sandbox. - Renamed exr -> openexr, since we might as well use the full name of the format. This was necessary to get Fyre 0.9 to find its datadir at all on my machine. After this fix, it works great. Thanks Cory!
Created attachment 51636 [details] Fyre 1.0.0 ebuild Here's the updated ebuild for fyre 1.0.0. Untar this to your local portage tree. Enjoy.
Just want to mention that this compiles and runs fine on my AMD64 laptop using GCC 3.4.3-r1. Looking forward to it getting into portage.
Just tried out the 1.0.0 ebuild in attachment 51636 [details]. The patch to stop the mime updates applied to data/Makefile.am but did no good, as the hooks remain in Makefile.in and Makefile. A copy of the emerge log is attached.
Created attachment 65633 [details] log of failed emerge failed emerge log of fyre-1.0.0.ebuild (as above)
Fyre 1.0.0 ebuild works nice for me in x86.
Created attachment 65733 [details] fyre-1.0.0.ebuild Some cleanup and fixes. Note that we can set update_xdgmime=/bin/true update_fdodesktop=/bin/true to make install, so patching the Makefile.am is not required. Don't install the initscipt if USE="-cluster". Use use_enable for configure arguments. Actually use fdo-mime functions. Plus a few minor issues.
Created attachment 65734 [details] fyre-1.0.0.ebuild Some cleanup and fixes. Note that we can set update_xdgmime=/bin/true update_fdodesktop=/bin/true to make install, so patching the Makefile.am is not required. Don't install the initscipt if USE="-cluster". Use use_enable for configure arguments. Actually use fdo-mime functions. Plus a few minor issues.
Created attachment 65735 [details, diff] fyre-1.0.0-initscript.diff
Created attachment 114094 [details] fyre-1.0.1.ebuild Ebuild for version 1.0.1 - verified to work on amd64 - uses gnome2 eclass for icon, .desktop, mime etc. handling - cleaned up dependencies - cleaned up init script
Created attachment 114095 [details] files/fyre-1.0.1-conf
Created attachment 114097 [details] files/fyre-1.0.1-init Put the new init script in files/ directly, since a patch would be larger than the script itself...
I've put the fyre-1.0.1 ebuild in the gentoo-sunrise overlay: http://gentoo-sunrise.org/svn/reviewed/media-gfx/fyre/ You can use layman to get updates (layman -a sunrise).
Created attachment 114412 [details] fyre-1.0.1.ebuild * Don't use gnome2.eclass; this is *not* a Gnome package; use fdo-mime.eclass * Dependencies on glib and gtk+ are needed; they are specified in configure.ac * Use emake for make install * Quote paths correctly * Use newconfd, newinitd
Created attachment 114413 [details] fyre-1.0.1-conf Add FYRE_USER="nobody"; we shouldn't be running this as root
Created attachment 114415 [details] fyre-1.0.1-init Add FYRE_USER; provide defaults for options
(In reply to comment #29) > * Don't use gnome2.eclass; this is *not* a Gnome package; use fdo-mime.eclass No. You are forgetting you need to update the gtk icon cache. If you are allergic to gnome, you will need to copy-paste several dozen lines from gnome2 and gnome2-utils. Which would be silly and very wasteful of bandwidth. By the way, why do you think non-gnome packages shouldn't use the gnome2 eclass? Is there some sort of official gentoo policy on this? > * Dependencies on glib and gtk+ are needed; they are specified in configure.ac No; libglade rdepends on glib and gtk+ -- adding unnecessary explicit dependencies only slows down portage. I mean, fyre also requires libc, but you are not going to add it to rdepend, are you? > * Use emake for make install Already in sunrise > * Quote paths correctly Already in sunrise > * Use newconfd, newinitd Already in sunrise > Add FYRE_USER="nobody"; we shouldn't be running this as root No. First, fyre-1.0.1 already runs as nobody (ps aux | grep fyre). And second, start-stop-daemon --chuid nobody makes the fyre daemon fail! > provide defaults for options That is an excellent idea.
> > * Dependencies on glib and gtk+ are needed; they are specified in configure.ac > > No; libglade rdepends on glib and gtk+ -- adding unnecessary explicit > dependencies only slows down portage. I mean, fyre also requires libc, but you > are not going to add it to rdepend, are you? Never mind, you are right, I am wrong. I just remembered why I always use emerge --deep. Will fix.
Created attachment 114432 [details] fyre-1.0.1.ebuild the latest from sunrise, now with correct dependencies
Created attachment 159964 [details, diff] File Dialog Patch File dialogs were not working for me in Fyre. Ubuntu Hardy members seem to have the same problem. I found the trick was to pause rendering whenever the file dialog windows opened so I threw together this patch to do it automatically. I'm new to both gentoo and this bugzilla thing...and I'm not much of a coder...so I hope this is okay.
Created attachment 159966 [details] Updated ebuild to apply the file dialog patch Updated ebuild to apply the file dialog patch
(this is an automated message based on filtering criteria that matched this bug) Hello, The Gentoo Team would like to firstly thank you for your ebuild submission. We also apologize for not being able to accommodate you in a timely manner. There are simply too many new packages. Allow me to use this opportunity to introduce you to Gentoo Sunrise. The sunrise overlay[1] is a overlay for Gentoo which we allow trusted users to commit to and all users can have ebuilds reviewed by Gentoo devs for entry into the overlay. So, the sunrise team is suggesting that you look into this and submit your ebuild to the overlay where even *you* can commit to. =) Because this is a mass message, we are also asking you to be patient with us. We anticipate a large number of requests in a short time. Thanks, On behalf of the Gentoo Sunrise Team, Jeremy. [1]: http://www.gentoo.org/proj/en/sunrise/ [2]: http://overlays.gentoo.org/proj/sunrise/wiki/SunriseFaq
Created attachment 215715 [details] fyre-1.0.1.ebuild (New Package) Some fixes.
Created attachment 215732 [details] fyre-1.0.1.ebuild (New Package) This is now in the sunrise overlay. You can find it at: http://overlays.gentoo.org/proj/sunrise/browser/sunrise/media-gfx/fyre DEVs, please add "InOverlay" in Keywords
This package has been removed from sunrise overlay as the ebuild fails to build.
