As mentioned already in the oyranos-0.9 version bump bug, it currently does not work when built against elektra-0.8.3 - at least not using kolor-manager-0.99. kolor-manager crashes at startup with the following message: $ systemsettings: symbol lookup error: /usr/lib64/elektra/libelektra-resolver.so: undefined symbol: elektraPluginExport
I have the same problem. The library is missing a required other library. Link additionally against one of those: /usr/lib64/libelektra-full.so /usr/lib64/libelektra.so If I preload one of them the oyranos plugin works. E.g.: LD_PRELOAD=/usr/lib64/libelektra.so systemsettings I'm not familiar with cmake so I don't have a patch for elektra right now.
Indeed, that fixes the problem.
I reported this at gentoo, and they told me that oyranos is not compatible with elektra-0.8, but 0.7 has to be used instead. See here: https://bugs.kde.org/show_bug.cgi?id=314827 And indeed, downgrading elektra (and rebuilding oyranos) fixes this
Yes, elektra-0.7 would be the correct dependency for oyranos-0.9 currently. It is plain old though. Some effort has been made already to port it over to elektra-0.8, but oyranos upstream seems to struggle getting it done. Having preloaded /usr/lib64/libelektra.so I see the same busy log as Kai-Uwe Behrmann in his quest for elektra-0.8.
I'm adding media-libs/oyranos maintainer. May be a blocker should be added to media-libs/oyranos until a patch / workaround / new release upstream (hopefully) will be ready
We now have the opposite situation that oyranos-0.9.4 depends on >=elektra-0.8.3-r1 which doesn't work at runtime.
Created attachment 343040 [details, diff] elektra-0.7.1-r3.ebuild.diff Don't rename include files but move them into 'elektra' subdirectory to make package more compatible.
Created attachment 343042 [details, diff] oyranos-0.9.4.ebuild.diff Depend on elektra-0.7.1-r3 and make use of FindElektra.cmake which is now able to find it. No sources modification for <elektra-0.8 needed anymore.
I'd say please just stop unbundling elektra from oyranos. The relationship between these two libraries is too fragile, and I am not sure that it is a good idea to allow the user of oyranos to build elektra with arbitrary options.
Andreas Sturmlechner: could you please confirm that oyranos works as it should (instead of just not crashing) with your patch? The test is to run: oyranos-monitor -l It should produce non-empty output. For me, it only does so if I undo the unbundling of elektra.
(In reply to comment #10) > could you please confirm that oyranos works as it should (instead of just > not crashing) with your patch? The test is to run: > > oyranos-monitor -l Hmm, indeed, there's no output. So far I have only been looking at kolor-manager as I'd like to have that usable some point in the future, and just settled for no crash -> fine for me for now.
However, it works when I modify oyranos-0.9.1-r1 to use my attached elektra-0.7.1-r3 ebuild that is attached. So something needs to be done with oyranos-0.9.4 still.
Created attachment 343748 [details, diff] oyranos-0.9.1-r2.ebuild.diff Here's the ebuild, if you want to give it a try as well. $ oyranos-monitor -l WARNING 0.010000: oyOptions_s[0]="oyOptions_s" oyranos_monitor_x11.c:429 oyX1GetMonitorInfo_() found /var/log/Xorg.0.log in ":0.0": LEN 4433 1920x1200+0+0 WARNING 0,010000: oyOptions_s[0]="oyOptions_s" oyranos_monitor_x11.c:465 oyX1GetMonitorInfo_() no EDID available from X properties: "XFree86_DDC_EDID1_RAWDATA"/"EDID_DATA" using Xorg log fallback. 0: ":0.0" 1920,00x1200,00+0,00+0,00 4433_xorg.icc Also, kolor-manager-0.99 lets me configure lots of things without a crash.
Alexander: However, portage ebuilds work as well if you take care of the deps, so maybe you've got a different problem? Got a positive test result using: elektra-0.7.1-r2 oyranos-0.9.1-r1
Well... `oyranos-monitor -l` doesn't work with bundled elektra either (in oyranos-0.9.4). In case this is an upstream bug, it isn't yet fixed in -9999 either.
(In reply to comment #7) > Created attachment 343040 [details, diff] [details, diff] > elektra-0.7.1-r3.ebuild.diff > > Don't rename include files but move them into 'elektra' subdirectory to make > package more compatible. This patch is kinda hidden, for an elektra fix. done. + 13 Apr 2013; Michael Weber <xmw@gentoo.org> elektra-0.7.1-r3.ebuild: + Move elektra include file in subdir (bug 447246, Andreas Sturmlechner) +
(In reply to comment #9) > I'd say please just stop unbundling elektra from oyranos. not an option (In reply to comment #12) > However, it works when I modify oyranos-0.9.1-r1 to use my attached > elektra-0.7.1-r3 ebuild that is attached. So something needs to be done with > oyranos-0.9.4 still. all suggested changes added as oyranos-0.9.1-r2. (In reply to comment #12) > However, it works when I modify oyranos-0.9.1-r1 to use my attached > elektra-0.7.1-r3 ebuild that is attached. can you please confirm this in some hours after an fresh sync with elektra-0.7.1-r3 and oyranos-0.9.1-r2, would be great. > So something needs to be done with oyranos-0.9.4 still. Masked for now Does not work with rdeps, mask for testing (bug #447246) + 13 Apr 2013; Michael Weber <xmw@gentoo.org> package.mask: + Does not work with rdeps, mask for testing (bug #447246) +
(In reply to comment #16) > This patch is kinda hidden, for an elektra fix. done. Sorry, I initially posted it here for oyranos-0.9.4 compatibleness. (In reply to comment #17) > can you please confirm this in some hours after an fresh sync with > elektra-0.7.1-r3 and oyranos-0.9.1-r2, would be great. Confirmed working on a second box that contains a radeon gpu. Also, same observations with oyranos-0.9.4/git on that box as above which where made on an i915 system.
I confirm that elektra-0.7.1-r3 and oyranos-0.9.1-r2, as found in the main portage tree, work together as they should. Also I have successfully tested them with compicc (which is unfortunately not in the portage tree).
oyranos-9999 works after removing the 0.9.4-buildsystem patch.
Same for oyranos-0.9.4
Wow, how did I miss that - easy fix for >=oyranos-0.9.4 in Gentoo: --- a/files/oyranos-0.9.4-buildsystem.patch 2013-03-23 19:17:07.000000000 +0100 +++ b/files/oyranos-0.9.4-buildsystem.patch 2013-04-21 10:57:42.256932742 +0200 @@ -5,9 +5,9 @@ LINK_DIRECTORIES( ${XCM_LIBRARY_DIRS} ) -FIND_PACKAGE( X11 ) -+IF(X11_WANT) ++IF(WANT_X11) +FIND_PACKAGE( X11 REQUIRED ) -+ENDIF(X11_WANT) ++ENDIF(WANT_X11) IF(X11_FOUND) INCLUDE_DIRECTORIES( ${X11_INCLUDE_DIRS} ) LINK_DIRECTORIES( ${X11_LIBRARY_DIRS} )
Created attachment 346224 [details] oyranos-0.9.4-patches.tar.xz Patches for: - bug 464254 - this bug (part buildsystem patch, part xrandr handling) - be on par with oyranos-0.9.1-r2 - many typos
Created attachment 346226 [details, diff] oyranos-0.9.4-r1.ebuild.diff - ebuild makes use of above patches - changed rdep to =app-admin/elektra-0.7* (-r2 should be dropped anyway) - bug 464094 fix for oyranos-0.9.4 as well - also contains oyranos.git URL for added fun
Alexander, want to give it a try?
The -9999 version needs other (=none) keywords, ${PN}-0.9.4 instead of ${P} for epatch calls, and the backported patches do not apply. My current portage state, both version show errors detecting elektra http://b-4.xmw.de/usr/portage/media-libs/oyranos/ http://b-4.xmw.de/var/log/portage/build/media-libs/oyranos-9999:20130422-114031.log http://b-4.xmw.de/var/log/portage/build/media-libs/oyranos-0.9.4-r1:20130422-105214.log
True, the live version is only meant to be used with the buildsystem patch. Strange, no elektra trouble on my system...
(In reply to comment #19) > ... tested ... with compicc (which is unfortunately not in the portage tree). Do you have an ebuild for inclusion? I couldn't find any trace on bugzie or gpo - besides upstream. http://sourceforge.net/apps/mediawiki/compicc/index.php?title=Main_Page
I just tried again, also using in-tree elektra-0.7.1-r3 and oyranos configured just fine: -- checking for module 'elektra' -- found elektra, version 0.7.1 -- Found ELEKTRA: /usr/include/elektra
(In reply to comment #27) > True, the live version is only meant to be used with the buildsystem patch. > > Strange, no elektra trouble on my system... nvm, it's the first run of the cmake-multilib fu that cannot detect the 32bit version of elektra on my multilib 64bit dev box.
ah yes, I haven't looked into that so far.
Created attachment 346294 [details, diff] oyranos-9999.ebuild.diff I guess that ebuild could work for both 0.9.4 and 9999 at the same time
Comment on attachment 346294 [details, diff] oyranos-9999.ebuild.diff ...except for some whitespace mess I just noticed
I see ebuilds are in portage now. :) Tested elektra-0.7.1-r4, oyranos-0.9.4-r1 successfully.
Just one more thing, oyranos-9999 already needs a change :) - CUPS macro names were fixed upstream and break 0.9.4-buildsystem patch: http://www.oyranos.org/scm?p=oyranos.git;a=commit;h=00da0f1e30b24fba9f07980596a8b30467145172 - FindXcm.cmake was removed in git - The s/Promt/Prompt sed can also be removed from the ebuild
Created attachment 346516 [details, diff] oyranos-0.9.5-buildsystem.patch new buildsystem patch
Created attachment 346518 [details, diff] oyranos-9999.ebuild.diff updated live ebuild
I think I said that before. I do not rely on $PV dependencies just to spare some duplicated bits between ebuild. Besides - as long as our VCS of (current) choice - cvs does not support symlinking, making that argument mute. I look into the fixes, but stop suggesting patches to merged -9999 and snapshots. And do not put version tags of unreleased versions to files. There is no way of telling final 0.9.5 will apply agains the 0.9.5 build system patch. This "if 9999" mess leads to toolchain.eclass and herds breaking stabilization rules arguing for convenience or even worst ... versioned eclasses.
+ 25 Apr 2013; Michael Weber <xmw@gentoo.org> oyranos-9999.ebuild, + +files/oyranos-9999-buildsystem.patch: + Update live version buildsystem patch (thanks Andreas Sturmlechner, bug + 447246) + This got too far off-topic, no need to annoy kde etc. Please report future issues as new bugs.
