Hi, I have 2 bugs during install of this ebuild. First, the ebuild won't compile with the "-arts" flag . Second, the executable krusader was installed in /usr/kde/3.3/bin which is not in my path (i have kde-base/kde-env-3-r3 installed on my system). My flag for this package were USE="-arts -debug -kde -xinerama" but the 2 bugs stay here with the "+kde" flag and the kde-base/kdebase ebuild installed. It seems like this bugs already exist in previous version, but i haven't test it (bugs #63976 : Krusader-1.40 wont compile when I haven't arts daemon ins...)
Created attachment 42266 [details, diff] resolution of this 2 bugs on my system I don't know if this bugs should be solved on the krusader ebuild, or directly in the kde eclass, but this modification of the ebuild have solved them on my system. So i'm not shure if it's a good job, but it works (for me at last). I've only modifies the original version by carlo by adding the line: #25 for arts problem, by adding, in all case, the --without-arts if necessary and the line: #30,31,32,33,34 for the path problem by create a symlink /usr/bin/krusader -> /usr/kde/${KDEDIR}/bin/krusader hope it could be usefull for other people (and may be used to solve the #63976 bugs on krusader-1.40), and many thanks to this beautifull distribution that is gentoo . PS:excuse for my poor english
Hello Dirk, cc'ing you to ask, if you can take care of this two issues upstream, please? :)
I think the reason, that the binary ends up in /usr/kde/${KDEDIR}/bin/ is the amd64 fix. According to Code Listing 19 at http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=2 it's not necassary to add src_compile() for "use" in the kde eclass. I attached an updated ebuild that should resolve this issue, the binary will got to /usr/bin again. And emerging the new ebuild with "USE=amd64 emerge krusader" adds the needed "-fPIC" (strangely it does it 3 times, but that shouldn't be a problem). As i don't have an amd64 myself, it would be great if some of the happier guys can test it. ;) Regarding the arts problem: I agree with chico76. It's probably something that has to be done in the eclass. I have never tried "-arts", do all the other KDE ebuilds work fine with it? If so i will try to add a workaround to the krusader ebuild.
Created attachment 42273 [details] krusader-1.50_beta1-r1.ebuild (should fix wrong path)
>Regarding the arts problem: I agree with chico76. It's probably something that has to be done in the eclass. I have never tried "-arts", do all the other KDE ebuilds work fine with it? If so i will try to add a workaround to the krusader ebuild. That's the main reason, why I cc'ed you. A lot of users don't want aRts anymore. We allow to disable it via the arts use flag (defined in kde.eclass - with the amusing side-effect, that arts itself has the arts use flag) and get the complaints if it does not work for some application. The most stuff does, though. Thanks for the amd64 pointer, I did not look at it yet.
Just to say that the ebuild from Dirk Eschler solved the 2 bugs (arts and path). This 2 bugs seems to become from the fact that the current ebuild don't pass throught the "myconf" section of kde.eclass which adds to $myconf the default kde configure script parameters. Currently, a lot of configure option were missing (see below for more details). In the Dirk Eschler's ebuild, it pass throught the "all" section (which make it pass through the "myconf", "configure" and "make section) as said about kde.eclass here: http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=2 and all works just fine (i don't know for the amd64). Last word to say that the 2 bugs and the configure option problem are yet present in krusader-1.40.ebuild due to the same fact. So i don't think that there is something to be done on the kde.eclass, but that change should be made on krusader-1.50_beta1 and krusader-1.40 Just to let you see what configure option were missing: $myconf state when entering case "configure" of kde_src_compil in the current version: + myconf=' --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib' $myconf state when entering case "configure" of kde_src_compil in the Dirk Eschler version: + myconf=' --host=i686-pc-linux-gnu --prefix=/usr --with-x --enable-mitshm --without-xinerama --with-qt-dir=/usr/qt/3 --enable-mt --disable-dependency-tracking --disable-debug --without-debug --without-arts --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib' So i think this bug is more than a USE='-arts" problem Many thanks for your quick solution. I attached an ebuild that does the same as Dirk Eschler ebluid but who adds the needed -fPIC only one time (i don't know if its important but ...)
Created attachment 42306 [details] krusader-1.50_beta1 (should fix all)
chico76: Your ebuild works for me. But there is one problem, had the same one while i was working on a solution for the arts issue myself (see 1c below). Carsten Lohrke: I see. Krusader itself should not depend on arts. I managed to compile it without and made a new ebuild (find it attached as krusader-1.50_beta1-r2.ebuild): 1) Added a line use "arts || myconf="--without-arts" a) Works if arts is installed and "USE=-arts" b) Works if arts is not installed and "USE=-arts" (yes i unmerged it just to be sure ;) c) Does not work if arts is not installed and "USE=arts". Reason: arts won't become a dependency and the configure script fails. 2) To avoid 1.c), add "arts? ( >=kde-base/arts-1.2.0 )" to DEPEND Now i'm not sure if this a reasonable way of doing it, or just a dirty workaround, and better stick with chico76's updated ebuild, or find another solution?
Created attachment 42313 [details] krusader-1.50_beta1-r2.ebuild (adds possible -arts workaround)
I haven't think about the erts depend, adding "arts? ( >=kde-base/arts-1.2.0 )" to DEPEND seems to be a good solution for me (but its only my third day of trying to understand ebuild, so...) But i don't understand why you would add "use arts || myconf="--without-arts" because if i'm true, the arts flag bug isn't particular to arts but is due to the "kde_src_compile configure make" on the original ebuild which pass over the config step of the kde_src_compil function. making a real mistake by causing the "untreatement" of a big party of the configure option (including prefix, host, use flag, etc...). So i think a good solution should be to mixed up our 2 last ebuild to make the one that i attached next (as krusader-1.50_beta1-r1.ebuild) By analyzing your depend arts problem i've been asking me the question for other package, and try this on kdetoys, which has the same problem as what we have with our last version (won't compile if USE="arts" and arts not installed). So i don't know : -How many package would have the same problem ? -Should i make another bug report for kdetoys (and may try to find other package in the same case) ? -If the "arts? ( >=kde-base/arts-1.2.0 )" should be put in each package who have this problem or if this must be added in the kde.eclass which resolved (i've tested it) the arts depend problem for krusader, kdetoys (and may a lot of other ebuild because kdetoys is just the first that i've tried) and seems more clean to me but as i said before i'm really a newbie in ebuilding. So i put a new version of the krusader, but i think that my last release is better than this one and that this depend problem about arts should be solved in kde.eclass (which is from where the use flag come and were it is treated). PS:Excuse my poor english, i hope that what i say is understandable
Created attachment 42320 [details] added arts depend I think that the "arts? ( >=kde-base/arts-1.2.0 )" should be add to kde.eclass
I've modified the kde_src_compile line to take this into account I don't think we wnat to add the dependency on arts, because the real dependency here is that kdelibs was compiled with arts support. If that hasn't happened, you will fail with an error anyway.
I think that this bug can be closed as krusader-1.50 supports --without-arts. Please reopen if I'm wrong.