Ebuilds for gaim-xfire no longer exist in Gentoo. Here's one for the recent 0.7.0. Reproducible: Always Steps to Reproduce: No step required I've also created a patch to fix oddities when dealing with IP addresses as gfire plugin is put in debug mode. The patch displays IP address numbers rounded to unsigned bytes.
Created attachment 176391 [details] ebuild for gfire-0.7.1 Uses EAPI-1.
Created attachment 176393 [details, diff] Fixes IP addresses oddities when printed in debug mode
Created attachment 176394 [details] Example game launch info file for Unreal Tournament 2004 I've also tested joining a game and, finally, it works! Here's an example ~/.purple/gfire_launch.xml for Unreal Tournament 2004. Its syntax has changed a little since version 0.6.x.
May this package be included in portage if I modestly suggest myself as the maintainer? I honestly believe it'll be useful -- I've waited long enough for the Join Game feature to work :-D .
Created attachment 192249 [details] gfire-0.8.1.ebuild Completly rewritten ebuild file for the Pidgin IM - Xfire protocol plugin. j0inty
(In reply to comment #5) > Completly rewritten ebuild file for the Pidgin IM - Xfire protocol plugin. > > j0inty Thanks, Steffen.
Created attachment 195098 [details] Updated ebuild posted by j0inty. Works with 0.8.2 now. Updated ebuild posted by j0inty to fix issue where it would not compile because the configure file was located in a sub-directory. Works with gfire 0.8.2 now.
(In reply to comment #7) > Created an attachment (id=195098) [edit] > Updated ebuild posted by j0inty. Works with 0.8.2 now. > > Updated ebuild posted by j0inty to fix issue where it would not compile because > the configure file was located in a sub-directory. Works with gfire 0.8.2 now. > Hi, 1. Your ebuild doesn't work for me... arko ~ # LC_ALL="C" ebuild /usr/local/portage/x11-plugins/gfire/gfire-0.8.2.ebuild digest : command not foundx11-plugins/gfire/gfire-0.8.2.ebuild: line 4: : command not foundx11-plugins/gfire/gfire-0.8.2.ebuild: line 9: : command not foundx11-plugins/gfire/gfire-0.8.2.ebuild: line 14: : command not foundx11-plugins/gfire/gfire-0.8.2.ebuild: line 16: : command not foundx11-plugins/gfire/gfire-0.8.2.ebuild: line 18: : command not foundx11-plugins/gfire/gfire-0.8.2.ebuild: line 21: 'usr/local/portage/x11-plugins/gfire/gfire-0.8.2.ebuild: line 22: syntax error near unexpected token `{ 'usr/local/portage/x11-plugins/gfire/gfire-0.8.2.ebuild: line 22: `src_compile() { * * ERROR: x11-plugins/gfire-0.8.2 failed. * Call stack: * ebuild.sh, line 1879: Called _source_ebuild * ebuild.sh, line 1818: Called die * The specific snippet of code: * source "${EBUILD}" || die "error sourcing ebuild" * The die message: * error sourcing ebuild * * If you need support, post the topmost build error, and the call stack if relevant. * This ebuild is from an overlay: '/usr/local/portage/' 2. You change the SRC_URI to a staitc sourceforge mirror, but what is when this gone offline ??? The gentoo group introduce this not why they fell free. @ALL Don't use the ebuild from "Caleb Morse", this isn't correct and invalid in syntax. Simply rename my ebuild to gfire-0.8.2.ebuild and hf&gl. j0inty
(In reply to comment #7) > Created an attachment (id=195098) [edit] > Updated ebuild posted by j0inty. Works with 0.8.2 now. > First thx a lot for the ebuild. I'm using it successfully. As far as I can see all the pidgin related add-ons follow the naming conventions pidgin-plugin_name, which is nice idea because it helps finding them in the official portage tree. As I would like to see this tool in official tree some day, maybe renaming the ebuild to follow this policy would speed up the process.
Created attachment 199071 [details] Updated ebuild posted by j0inty, to follow the naming pidgin-plugin_name I edited the ebuild to make it follow the naming convention pidgin-plugin_name. It works for me.
Created attachment 201650 [details] SVN Version of the ebuild Current release of gfire 0.8.2 is no longer able to connect to xfire network. So i change the ebuild to pull svn version.
Created attachment 201744 [details] latest stable release This release is stable and able to connect to xfire 113.
Created attachment 203226 [details] pidgin-gfire-0.8.3 ebuild ('cd' statements removed) The 'cd' statements are not needed if you save the ebuild in <portage overlay directory>/x11-plugins/pidgin-gfire/ instead of <portage overlay directory>/x11-plugins/gaim-xfire/.
CC'ed to see what you guys are doing :) I could also offer myself as a maintainer for this, but I'm not very experienced with writing ebuilds so I gotta read some docs on that first. And maybe it's not that good to have a Gfire dev as Gfire package maintainer.
I suggest the version number be removed from the title of this report: x11-plugins/pidgin-gfire - "an open source plugin for the Pidgin IM client which allows you to connect the Xfire network" as it no longer relates to one single version. Can somebody kind enough do that for us please? ;-)
Vince, you're the reporter, can't you do that?
(In reply to comment #16) > Vince, you're the reporter, can't you do that? > Erm... Sorry... I can be so st00pid at times! (ashamed)
Created attachment 226329 [details] Ebuild for new version gfire 0.9.0 Rewritten ebuild for new version of gfire 0.9.0. It was working for me, hope it will be useful to someone else.
Created attachment 226331 [details] Updated Live ebuld for svn version of Gfire Latest one wasn't working, so I change it a little bit. This one pulled and compiled the gfire fine on my machines.
Created attachment 226417 [details, diff] pidgin-gfire-ge-0.9.0_dbus-libnotify.patch Hi, As I was testing the new 0.9.0 ebuild I saw that the libnotify and dbus support wasn't compiled in. Here is a little patch to add this support if the use flags are in use. regards j0inty
, > > As I was testing the new 0.9.0 ebuild I saw that the libnotify and dbus support > wasn't compiled in. > Thx for pointing this out. I applied your patch and added new use flag srvdetection to pull the tcpdump[suid] needed for server detection to work. Server detection is experimental I found out it's working only for limited number of games. Will post new version of ebuild right away.
Created attachment 228387 [details] New fixed version of ebuild with srvdetection use flag
Created attachment 228389 [details] New fixed version of live ebuild with srvdetection use flag
Created attachment 228393 [details] Use flag metadata information for ebuilds
Created attachment 228457 [details] fixed version of ebuild with missing gtk use flag I spoke about issue I had with gfire with oGGy upstream developer he pointed out that there is also a gtk flag in configuration possible to use, I also added more detailed use flag dependencies.
Created attachment 228459 [details] fixed version of live ebuild with missing gtk use flag
Shouldn't we add nls USE flag? NLS support is optional with this plugin.
(In reply to comment #27) > Shouldn't we add nls USE flag? NLS support is optional with this plugin. > Disabling nls wasn't changing anything for this packet. Translation files are generated (of course if your linguas match the packet available linguas) regardless the nls flag is enabled or disabled so adding this option for the 0.9.0 or 0.9.1, doesn't change the way the program will install. I spoke with oGGy the upstream developer about this issue, it was cosed by core inittool generation. He already fixed it on svn version. So for live version and any new version that will be released nls will disable the translation files (*.mo) generation. I'm adding the nls flag to live ebuild. If you don't want to have nls now you can disable it. As for 0.9.1 this issue is still present I will not add this flag. Judging by your name (correct me if I'm wrong) you may be interested that in svn version there is also new polish translation I made yesterday. I will submit new ebuilds in just a moment.
Created attachment 230045 [details] New live ebuild with nls use flag You can now disable *.mo translation files generation by setting USE="-nls", this way you will have a default english language in gfire plugin
Created attachment 230047 [details] Ebuild for new version gfire 0.9.1 This release removes some problems with games running on wine detection.
Created attachment 234767 [details] Ebuild for new version gfire 0.9.2 with nls use flag Added nls use flag for this ebuild, disabling this flag for 0.9.2 will disable *.mo files generation.
I've committed an ebuild for pidgin-gfire-0.9.2 to Sunrise; requesting that the KEYWORD 'InOverlay' be added to this report. Also note that I didn't include a 'srvdetection' USE flag, as I couldn't get server detection to work, and having a dependency on net-analyzer/tcpdump[suid] seemed a little too mucky (hopefully upstream will amend this someday).
Created attachment 264377 [details] Ebuild for new version 0.9.3 This is just rename, I checked the ebuild end it's working. (In reply to comment #32) > > Also note that I didn't include a 'srvdetection' USE flag, as I couldn't get > server detection to work, and having a dependency on net-analyzer/tcpdump[suid] > seemed a little too mucky (hopefully upstream will amend this someday). > I'm keeping the srvdetection flag (it's not perfect solution I agree) but it's working for some titles, for example it's working for ventrilo running on wine. The current version is available (with srvdetection flag) in my private overlay. More information here: http://www.kardasa.pl/english/overlay_eng.html
Hello, everyone. It seems that at least one ebuild related to this bug exists in the Sunrise overlay at the moment. However, I have to regretfully announce that after a long inactivity period the Sunrise project has been discontinued and the related overlay will be eventually removed. For this reason, I'd like to ask you to reevaluate the ebuilds and consider moving them. If you'd like to maintain a package from Sunrise in Gentoo, please take a look at our Proxy Maintainers [1] project. Please make sure to take ebuilds from the unreviewed developer Sunrise repository [2] rather than the -reviewed one, since the latter has not been updated for over a year. While at it, please note that: 1. Adding a package to Gentoo requires declaring yourself as an active maintainer for it. All bugs regarding the package will be assigned to you, and you will be expected to maintain it. 2. Some packages may not be suitable for addition anymore. While there's no strong rules that would prevent you from adding a package, it may be a bad idea to add old-unmaintained packages that will shortly result in a large number of bugs reported with no solution. If that is the case, please close the bug as RESOLVED/OBSOLETE to make it easier to find packages worth adding. 3. Some of the bugs were already closed as WONTFIX/OBSOLETE/... while the relevant ebuild was kept in Sunrise. If you disagree with the original decision, you still can add the ebuild via proxy-maint. 4. Pleaes note that many of the Sunrise ebuilds are old and may be buggy. If you decide to move them, please make sure to update/clean them up. The proxy-maint team will also review your ebuilds, therefore making sure they land in Gentoo in good quality. Once again, thank you for your contribution. We hope that you will still want to contribute to Gentoo, through proxy-maint or otherwise. [1]:https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers [2]:https://gitweb.gentoo.org/proj/sunrise.git/
The Gfire project is dead, it was a compatibility layer for Xfire Games communicator for Linux users. As Xfire died so is Gifre, so there is no need to maintain it.
R.I.P.
Thank you for letting us know :)
