Created attachment 348824 [details] suggested ebuild for rodent-5.0.3 Rodent-5.0.3 is now available at http://sourceforge.net/projects/xffm/files/5.0.3/rodent-5.0.3.tar.bz2/download Attached you will find my *suggested* modifications to the current ebuild. USE flags are defined to introduce run time dependencies. These dependencies may will not halt build of rodent-5.0.3, but will produce a "Please install xxx" notice if action taken by the user will require xxx. Defining the USE flags is for make things easier to install everything rodent might require in a single shot. I've also removed the line: inherit xfconf because it is not necessary and just introduces unused dependency. TIA.
Comment on attachment 348824 [details] suggested ebuild for rodent-5.0.3 --- rodent-4.9.2.ebuild 2013-04-17 16:07:49.787597220 +0200 +++ - 2013-05-21 16:31:11.808779465 +0200 @@ -4,16 +4,16 @@ EAPI=5 EAUTORECONF=yes -inherit xfconf +#not needed anymore: inherit xfconf DESCRIPTION="A fast, small and powerful file manager and graphical shell" HOMEPAGE="http://rodent.xffm.org/" -SRC_URI="mirror://sourceforge/xffm/${PV}/${P}.tar.gz" +SRC_URI="mirror://sourceforge/xffm/${PV}/${P}.tar.bz2" LICENSE="GPL-3" SLOT="0" KEYWORDS="amd64 x86" -IUSE="experimental" +IUSE="sshfs nfs ecryptfs ftpfs bluetooth cifs gvfs bcrypt zip" COMMON_DEPEND="x11-libs/libX11 x11-libs/libSM @@ -22,16 +22,27 @@ x11-libs/gtk+:3 >=x11-libs/cairo-1.8.10 >=gnome-base/librsvg-2.26 - >=dev-libs/libzip-0.9 sys-apps/file" RDEPEND="${COMMON_DEPEND} - gnome-base/gvfs" + app-text/ghostscript-gpl + zip? ( dev-libs/libzip ) + gvfs? ( gnome-base/gvfs ) + sshfs? ( sys-fs/sshfs-fuse ) + nfs? ( net-fs/nfs-utils ) + ecryptfs? ( sys-fs/ecryptfs-utils ) + bluetooth? ( + sys-fs/obexfs + net-wireless/bluez + ) + cifs? ( net-fs/samba ) + bcrypt? ( app-crypt/bcrypt ) + " DEPEND="${COMMON_DEPEND} dev-util/intltool virtual/pkgconfig" pkg_setup() { - XFCONF=( $(use_enable experimental) ) + XFCONF=( $(use_enable sshfs nfs ecryptfs obexfs cifs gvfs) ) DOCS=( ChangeLog README TODO ) PATCHES=( "${FILESDIR}"/${P}-rupo.patch ) }
(In reply to comment #1) > Comment on attachment 348824 [details] > suggested ebuild for rodent-5.0.3 > > --- rodent-4.9.2.ebuild 2013-04-17 16:07:49.787597220 +0200 > +++ - 2013-05-21 16:31:11.808779465 +0200 > @@ -4,16 +4,16 @@ > > EAPI=5 > EAUTORECONF=yes > -inherit xfconf > +#not needed anymore: inherit xfconf It's used for multiple things, PATCHES=(), XFCONF=() and eg. updating desktop caches, gtk+ icon caches, punting .la files, etc > - XFCONF=( $(use_enable experimental) ) > + XFCONF=( $(use_enable sshfs nfs ecryptfs obexfs cifs gvfs) ) weird use of use_enable, is that really valid?
Oops. "use_enable" is a typo! I really hate these touchpads, I must have forgotten to disable it at some point. I wasn't aware of all the functionality implied by xfconf. I suppose it should be kept.
Created attachment 349504 [details, diff] patch to version bump 4.9.2-->5.0.4 Ebuild was not working for 5.0.3: something about a QA problem. This was due to an error in a certain Makefile.am. I've fixed the problem in 5.0.4 (now at the download site) and tested the ebuild satisfactorily in a fresh Gentoo install. Find my suggested ebuild in the proposed patch. TIA.
Seems something is wrong with the ebuild. librun plugin fails to load from rodent-fgr executable, but loads fine from rodent executable.
Quite strange. Rodent-fgr will load librun.so plugin fine if I compile and install from source, but not from ebuild. I'll do some more ebuild studying to try and figure it out. Any ideas where to start?
Possibly related to the use_enable? It's still wrong in the patch you supplied. You need to use a single use_enable for every single option available. Also, are all of the dependencies in RDEPEND really only needed during runtime?
Created attachment 349752 [details, diff] ebuild 4.9.2 --> 5.0.5 patch Thanks for the tips. I've corrected the patch. I didn't quite understand the usage of "use-enable". Now I see that it was not necessary in the ebuild, as the IUSE and RDEPEND take care of business. All dependencies listed in the RDEPEND are *only* needed at run time and may be installed later if user requires the functionality provided by the RDEPEND item. If the user tries to use the RDEPEND item functionality before the item is installed, rodent will kindly suggest that the item be installed. Rodent is programmed on a modular plugin design so that functionality can be added (or removed) without recompilation. I could not find the reason why the ebuild compilation ebuild fails to load the necessary module in the find dialog program (some optimization thing, I guess). But since only a small routine is needed from the module, I just included it in the executable. This is why the version is now bumped to 5.0.5 (now released), with the attached patch. I've tested it successfully.
The linker fails w/ rodent 5.1.3 and the following libraries dbh-5.0.8 librfm5-5.1.4 libtubo-5.0.10 If someone has any clue why ldd returns librfmlibrfm1.so.1.so.1 => not found librodentlibrodent1.so.1.so.1 => not found when the libraries are respectively librfm1.so.1 and librodent1.so.1 ?
Created attachment 362730 [details] libtubo
Created attachment 362732 [details] dbh-5.0.8 ebuild
Created attachment 362734 [details] librfm5-5.1.4 ebuild
Created attachment 362736 [details, diff] patch for rodent 5.1.3
This issue has had me chasing my tail for a while. For some strange reason libtool is specifying -soname as "librfmlibrfm1.so.1.so.1" for librfm.la and "librodentlibrodent1.so.1.so.1". You can see this in the link step as "-Wl,-soname -Wl,librodentlibrodent1.so.1.so.1" added by libtool. I've asked on the libtool list why these dorky names are being set as the "dlname" in librfm.la and librodent.la, but received no answer. And when I tried to specify the -soname option, I found that it is not user configurable. Once the link step is complete, the symlinks with these dorky names are *not* created (hence you cannot find them if you try to link with the .la file). But curiously enough, they *are* created when you run make install (which in turn will trigger a libtool --mode=install). Furthermore, with basically the same structure of Makefile.am, neither libtubo nor dbh will construct a dorky -soname in the .la file. Something must be different. Trying to track down what libtool is doing, I reached this line: func_basename_result="${1##*/}" of which I have yet to figure out what it means. I would be very happy to get rid of these dorky names, if only I knew why libtool uses them. In Gentoo I don't have any problem linking Rodent if I install librfm prior to compiling rodent, as this will create the symlinks specified as dlnames in the .la files.
I figured out what was happening. A macro in configure.ac script was borking things for the libtool scripts. librfm5-5.1.5 is now available at download site with this libtool error now corrected.
I've now released 5.2.0, which includes ebuild I've tested that seem to work OK. I will now attach these ebuilds.
Created attachment 366468 [details] libdbh2-5.0.13 ebuild
Created attachment 366470 [details] libtubo0-5.0.14 ebuild
Created attachment 366472 [details] librfm5-5.2.0 ebuild
Created attachment 366474 [details] rodent-5.2.0 ebuild
ebuild tested. Works nicely. Just think about emerge -C the previous rodent version to avoid librfm conflicts. Or better, add a conflict in the ebuild since librfm5 is pulled before the replacing rodent ebuild, since its a dep.
I suppose adding the following to the RDEPEND variable would do the trick for upcoming 5.2.4 release: !<x11-misc/rodent-5.2.4 Please correct me if I'm mistaken.
Created attachment 370790 [details] ebuild for librfm 5.2.5 Works for me.
Created attachment 370792 [details] ebuild for rodent 5.2.4
Upstream is at 5.3.16.3 now. Also, the homepage is http://xffm.org/, not http://rodent.xffm.org/.
Added 5.3.16.3 to the tree.
