aMule Forum
English => Distro-Specific Packages => Packages for development versions => Topic started by: libre on August 01, 2009, 10:15:44 PM
-
I updated the wiki article with a working and current ebuild.
HowTo_Compile_In_Gentoo amule SVN (http://wiki.amule.org/index.php/HowTo_Compile_In_Gentoo#amule_SVN)
About the ebuild, it doesn't have an option for the xchat plugin. I guess that this it depend on net-irc/xchat. Which minimum version have this depend, and is it a runtime or compile time depend?
-
The xchat version doesn't matter, it even is not required while build. It's just a perl script, so you have to have a working perl-plugin for xchat to use it. Installation is just copy as is from sourcetree to install dir. The autostart-xas script links it to the location where xchat expects to scripts it should start on startup. If you don't need it autostarted, you can load it from install-dir.
-
Thanks.
So, it is a runtime dependency. With the other distributions, amule can be separated into several packages, one for amule, one for the xchat plugin, and so on. On Gentoo, we get the same with USE flags. They tell emerge which parts of the software the user want to install.
EDIT: ebuild updated with correct DEPEND + RDEPEND.
-
Ebuild updated for the 2_2_X trunk.
-
The last tarball need wxGTK-2.8.12. I updated the wiki with a link to an ebuild for wxGTK-2.8.12 on gentoo bugzilla.
The ebuild on the wiki get updated to reflect this change. An outdated USE flag have also been removed and 2 new USE flags have been added.
-
3 new USE flags in fact. I even added one for static build.
-
Ebuild updated to EAPI="3"
-
Hi,
Unfortunately it doesn't work anymore :(
make install-data-hook
make[6]: Entering directory `/var/tmp/portage/net-p2p/amule-10587/work/aMule-SVN-r10587/src/utils/plasmamule'
/usr/bin/update-mime-database /usr/share/mime/
/usr/bin/update-mime-database: I don't have write permission on /usr/share/mime. Try rerunning me as root.
-
I guess you're running it as root, so the question is: is your mime-database in the given location?
-
I do use portage to compile it, so yes, but it runs in a sandbox.
-
It does compile flawlessly without the plasma use flag.
Let me know when you fix it (a reply to this thread will be enough)
Thank you,
Darkbasic
-
If portage takes over env vars, you can export DEB_HOST_ARCH to any value and it should work. With this var detecion is done, if it's a deb build or not. If you know any way to detect if portage is building the source, let me know, and I include it in the check.
If the vars are not taken to the build-env, just remove the call of CHECK_HELPER_APPS in m4/plasmamule.m4 and rerun autogen.sh.
-
Sorry for the delay, I was very busy.
I get now (aMule-SVN-r10645) another error:
make install-data-hook
make[6]: Entering directory `/var/tmp/portage/net-p2p/amule-10645/work/aMule-SVN-r10645/src/utils/plasmamule'
/usr/bin/update-mime-database /usr/local/share/mime/
/usr/bin/update-mime-database: I don't have write permission on /usr/local/share/mime. Try rerunning me as root.
make[6]: *** [USER_INSTALL] Error 1
Also, at the beginning of portage log file:
kde-mime-path /usr/local/share/mime/
kde-applinks-path /usr/local/share/applications/
The other kde related paths are OK.
I can see 2 problems:
1) kde-mime-path and kde-applinks-path should point to /usr/* instead of /usr/local/*
2) install-data-hook don't understand the install path ($PREFIX) as specified by the ebuild
Also, I get it to work by specifying DEB_HOST_ARCH="no" into the ebuild, I will update the wiki in a few minutes, but 2 files are installed in the wrong location:
/usr/local/share/applications/plasmamule-engine-feeder.desktop
/usr/local/share/mime/amule.xml
-
It's not the wrong location, it's the location where kde expects them to be.
Try "kde4-config --path xdgdata-apps" and "kde4-config --path xdgdata-mime" to see what options you have. If installed to other path's than theses ones, kde won't find them and the app would be useless.
As for the DEB_HOST_ARCH, it's just to find out, if you build and install by hand or by a packager. If you build by hand, some commands are searched and executed after install, so kde get's informed about the new or updated apps, as otherwise nothing would happen until the next relogin into kde.
If you can tell me a way to how to examine this in gentoo, it will get included into the check.
-
kde4-config --path xdgdata-apps
/home/dom/.local/share/applications/:/usr/local/share/applications/:/usr/kde/3.5/share/applications/:/usr/share/applications/:/usr/share/gdm/applications/kde4-config --path xdgdata-mime
/home/dom/.local/share/mime/:/usr/local/share/mime/:/usr/share/mime/According to the FHS, /usr/local is for local files. That imply than, when installing a program with a package manager, no file should be installed in /usr/local. If it is the case, that imply than the program doesn't respect $PREFIX as fixed by the package manager, and this is a bug into the program.
In my box, the only files in /usr/local, at the exception of those 2, are from programs I installed by hand without portage's help. Also, it is normal than a soft like kde4-config will also take a look at /usr/local/.... If it doesn't take a look into /usr/..., this is a bug in kde4-config.
For your question, it must be possible to test for PORTAGE_BUILDDIR
This variable is defined only inside portage, if it is not null, you are in portage, otherwise, you are not. http://devmanual.gentoo.org/ebuild-writing/variables/index.html
Just to be sure, I asked on the gentoo forum http://forums.gentoo.org/viewtopic-t-898606-highlight-.html
-
I could not wait. The attached patch work for me with portage.
-
I get an answer from genome, a retired dev:
The proper solution would be to add a configure switch for it that the ebuild/specfile/whatever can enable/disable, not trying to detect it automatically. This type of auto-detection is generally rather fragile and disliked by package maintainers. A switch is much more reliable and can be used by everyone.
I thing he has right because anyone and any package manager can use it, and also because it will be much less maintenance in the long run (due to the fragility of the test and the possible necessity/will to add other package managers)
In consequence, I will let the ebuild like it is in the wiki for now. It work with the 10645 svn revision, and this is fine for me. Thank you for the good work on amule.
-
I can take a look at this on Sunday. As every Distro now has new enough KDE, the helper apps shouldn't be needed anymore, so the test and detection of the two apps can be dropped at all.
-
Thank you,
I reversed the cjange into the ebuild as it is not needed anymore.
-
It look like the wiki Requirements page is a little but outdated. http://wiki.amule.org/index.php/Requirements#Required It is no mention of plasma.
Regarding the ebuild, it look like I put a wrong plasma dependencies, which can explain some problems with it: plasma ? kde-base/kdelibs
And this is for kde3.
Do you know which plasma package is needed by amule? On gentoo, I found the followings:
kdeplasma-addons
libplasmaclock
libplasmagenericshell
plasma-apps
plasma-runtime
plasma-workspace
-
Oops, I am wrong. The kdelibs package exist for kde4 too. But it is no plasma use flag for it.
-
Intressting, as plasma came with kde4. kde3 can'thandle this. plasma-runtime should be enough (guessed by the name). MAybe the deps of plasma-apps or libplasmaclock give you a hint.
-
Due to a bad hard disk, I am on a new system. OK, no kde and portage tell me to install kdebase-meta or kdebase-startkde. Installing the second one.
Also, a problem with the ebuild. The plasma stuff need "inherit kde4-base" which in turn need EAPI="3". With that setting, emerge want to compile in some ../kde_build directory and it doesn't find it. Normal, amule is not a kde software. I added a src_compile() section into the ebuild and it work fine.
The wiki is updated. The joined file contain my current ebuild.