Bug 239936

Spec URL:
http://kwizart.free.fr/fedora/6/testing/oyranos/oyranos.spec
SRPM URL:
http://kwizart.free.fr/fedora/6/testing/oyranos/oyranos-0.1.7-3.kwizart.fc6.src.rpm
Description: The Oyranos Colour Management System (CMS)

Some updates (remaining rpaths)

Some random notes:

* Please make the compile log more verbose
* Add 'INSTALL="%{__install} -p" to make install
* What rpm own %{syscolordir}?
  (Please check directories' ownership)
* While %syscolordir is used, %{_datadir}/color/ is also used
  in spec file
* Is the definition %usercolordir needed (for this spec file)?
  (and there seems to be other unused macros)
* %configure already uses --libdir=%_libdir
* For make install:
--------------------------------------------------------
make DESTDIR=$RPM_BUILD_ROOT install install_gui
--------------------------------------------------------
  This will be sufficient.
* Would you tell me what %post script actually does?
  (especially, does %post script change some files?)

(In reply to comment #1)
> Some updates (remaining rpaths)
* Would you tell me what rpath issues remain? (mock build log
  may be useful)

* For %clean: why do you have to remove __doc directory explicitly?

Ok here is a state of art...
* Might requires also FLU
http://www.osc.edu/archive/FLU/
This one seems optionnal and also not supported with fltk = 1.1.7 (or =< also, i
suppose)

* I don't knwo why the compile log isn't more verbose at this time...
 (i expect some echo "what i'm doing "@..."
* OK it uses now install -p 
* About %{syscolordir} - diffents packages use this directory
yum whatprovides /usr/share/color show theses:
 epic / java-1.4.2-gcj-compat-javadoc / pork / python-kiwi-docs
 I think this should be owned by filesystem if it became a standard directory
* Removed %usercolordir others macros seems
* About Make install - Actually i think usersetting shouldn't be called at
buildtime but only in a %post section... using one line make install* for them.
* This post script install keys in elektra registry database, this is mandatory
to uses elektra with oyranos unless it will ask for this own version, with
static libs... Hope to have advices from Pertusus about theses...
* no more remaining rpath
* Since i uses temporary dir "__doc" to put the docs in the right place, i
thought i have to remove them ... I can also leave them here...

Spec URL:
http://kwizart.free.fr/fedora/6/testing/oyranos/oyranos.spec
SRPM URL:
http://kwizart.free.fr/fedora/6/testing/oyranos/oyranos-0.1.7-4.kwizart.fc6.src.rpm
Description: The Oyranos Colour Management System (CMS)

Well, I have not checked this in detail yet...

* Dependency
  - main package should have: 'Requires: %{name}-libs = %{version}-%{release}'
  - Check if -devel package should require main package (if you create
    library subpackage)

* %post
  - Well, then would you tell me what files does %post scriptlet
    change?

* About /usr/share/color
  - Well, this is not owned by any package on my system. So for
    now please make the directory owned by this package explicitly.

* build log
  - To make build log more verbose. please do:
---------------------------------------------------------------------------
for f in `find . -name [mM]akefile\*` configure.sh ; do sed -i.silent -e
'/.SILENT/d' $f ; done
---------------------------------------------------------------------------
    If makefile contains '.SILENT:' line, the make log is suppressed.

* fltk
  - Again, is fltk compatible with GPL?

Okay, now we can restart this review request as fltk license issue is solved.
So would you update the srpm again?

Ok i will update it...

For now, i've tested the build with cinepaint and it seems that the main oyranos
package is needed at runtime...So i expect that oyranos is not multilib
compatible. This mean that the libs requires the main package (with binaries) so
i will drop the -libs subpackage and ask for adding oyranos to some exclude
multilib list...

Spec URL:
http://kwizart.free.fr/fedora/6/testing/oyranos/oyranos.spec
SRPM URL:
http://kwizart.free.fr/fedora/6/testing/oyranos/oyranos-0.1.7-6.kwizart.fc6.src.rpm
Description: The Oyranos Colour Management System (CMS)

I've dropped the elektra key registration users should lauch oyranos to set the
default for it...

I didn't drop -libs sub-package... I'm still a little weak about multibs
compatibility... Actually, only cinepaint is using oyranos, so I will move
cinepaint for fc8 to multilibs compatibility...(and rebuild fc7 version that
live in testing becasue of that)
That will be the same scheme as gimp and gimp-libs...

To come... There is a new icc_examin 0.44 version that should build externally
(from cinepaint). But for now i'm only abble to build it internally from
cinepaint... I don't plan to work on it (externally) for Fedora 8...
But i will submit a review as soon as I have some success...

Currently I meet a strange buildroot failure on koji so I cannot
rebuild your new srpm and I am asking fedora-devel mailing list
why...

For 0.1.7-6:

* ldconfig
  - Please call ldconfig for -libs.
  - And main package does not seem to require
    ldconfig call

* pkgconfig .pc file:
  - fix up pc files
    * Name entry is the same
    * oyranos_monitor.pc
      - contains duplicate includedir entry
      - has strange Libs entry (-X11 ?)

* oyranos-config
--------------------------------------------------
[tasaka1@localhost oyranos]$ oyranos-config --version
0.1.7
Package elektra was not found in the pkg-config search path.
Perhaps you should add the directory containing `elektra.pc'
to the PKG_CONFIG_PATH environment variable
No package 'elektra' found
--------------------------------------------------
  - oyranos-config complains elektra.pc is not found
    (however I don't think oyranos-devel should require
     elecktra-devel)
  - And move the corresponding man file (oyranos-config.1)
    from main package to -devel subpackage.

* License
  - As far as I checked the actual source code, this
    is licensed under GPLv2+.

Spec URL:
http://kwizart.free.fr/fedora/6/testing/oyranos/oyranos.spec
SRPM URL:
http://kwizart.free.fr/fedora/6/testing/oyranos/oyranos-0.1.7-7.kwizart.fc6.src.rpm
Description: The Oyranos Colour Management System (CMS)

About oyranos-config. The better fix is to use pkg-config for apps that links to
oyranos, but for now cinepaint (and icc_examin, maybe others) still uses
oyranos-config. So for now the quickfix is to BuildRequires elektra-devel also... 

I will use, this in cinepaint to prevent linking issues:
# clean unused-direct-shlib-dependencies
sed -i -e 's! -shared ! -Wl,--as-needed\0!g' libtool

For -7:

* Again pc file
  - This time oyranos_monitor.pc has:
--------------------------------------------
Requires: x11 xinerama
--------------------------------------------
    This means that -devel package should have:
    "Requires: libX11-devel libXinerama-devel".

    However, are these Requires really needed?
    #include macro search returns:
--------------------------------------------
$ grep -h '#include ' `rpm -ql oyranos-devel | grep /usr/include` | sort | uniq
#include "oyranos.h"
#include "oyranos_definitions.h"
#include "oyranos_version.h"
#include <stdlib.h> /* for linux size_t */
--------------------------------------------
     and it does not seem to require those two -devel
     package.

* Documents
  - IMO all files "AUTHORS COPYING ChangeLog README" must be
    installed into -libs subpackage, because both main and -devel
    package require -libs subpackage.

ping?

So, i've made few improvements since devel was failed (because of Fedora ->
Pacakges changes during the freeze )

The above error are corrected but i still need to test why i have erros when i
removed commercial icc profiles... Whereas if I have them installed, there is
still the same error... I will do some testing with a fresh installed rawhide...

Now there is a new (optionnal) dependency. But there is a need to figure out
what to do with standard paths as it bundles also some icc profiles.

I've just remembered that oyranos is know as an alpha state (with 1.7), so maybe
i will wait for improvement before to continue the review...

Until then i will do some runtime test to provide a default profile suitable for
Fedora (meant using non-commercial icc profiles by default)...

Again would you update the status?

FE-LEGAL blocked: I would like to know if we are allowed to provides icc content...
There is differents License for theses contents from within this package (and
xcalib). I expect some of them to require to be removed... But I wonder if we
could leave some)...

Some usefull links about an open source version of Adobe icc:
http://lists.freedesktop.org/archives/openicc/2006q3/000748.html
http://lists.freedesktop.org/archives/openicc/2006q3/000764.html

As I have some standard profiles packaged in Oyranos, which further requires 
them to work correctly, I wonder how they should be packaged.
Oyranos creates several RPM's with the make rpm target. They contain
profiles sorted by licenses plus the binary and developers RPM. 

@Kai-Uwe Behrmann thx for joining
I would say, I will probably handle this somehow. the mandatory thing will be to
remove from the source archive of oyranos the icc profiles that cannot be
redistributed from the Fedora point of view.
Then I will probably take the "upstream" site of theses profiles to packages
them on a well know third part repository (if the site allow us to redistribute
them).

This may requires some naming rules from the new package (or I could stay with
 	oyranos-LStarRGB-0.4-16.1.noarch.rpm - what if I choose color-icc-LStarRGB for
example?)

I haven't checked which one could be allowed or not, maybe we could have the
compatibleWithAdobeRGB1998.icc but that's all. I wonder if i will split it to
another package (that will be required by oyranos)
Maybe cineon profiles can be allowed, in this case i may provide another package
with color-icc-Cineon

for LStar case - I wonder if we can allow it for Fedora (but not for EPEL) as:
Permission to use, copy, and distribute this profile and its documentation for
any other than commercial purpose (including bundling with products, enhancing a
product´s performance or value)... 

I don't know the status for HeidelbergLicense probably allowed to redistribute
but not Free (to modify, even if it does not make sense - so it will not be
allowed into Fedora).

The LStar profile will be replaced with ECIv2. It will become a ISO. Not shure 
when. The license is more liberal regarding distribution, but modification is
not allowed. 
http://www.eci.org/eci/downloads/ECI-de/iccprofile_der_eci/eciRGBv20.zip

I can relicense my profiles, the cineons, to be BSD. Would that help?

Recreation of any of the profiles, possibly except the cineons, should be easily 
possible with packages like ArgyllCMS or Scarse. So the ECI licenses should not 
hurt anyone. The base characterisation data to create the profiles is always 
open to use. We could even go as far to include the data files to make it 
convenient to create own profiles and let user do whatever they like with them.

For naming, I'd like to stay with oyranos in the package name to make it clear 
its the reference. Some features like user policy checking and colour
conversions rely on this. The standard profiles involved should be the same on 
every supported platform. The naming would help for this.

@Patrice Dumas
Are we expecting a the new elektra 7 for F-9, there is a rebuilt failure that we
need to fix for gcc43

I may use oyranos 1.8 depending if oyranos is rebased on elektra 7 or current 6.10.
Kai-Uwe any tips for this question ?

Indeed I am more or less waiting for 0.7., even a release candidate
since I remember a post on the mailing list showing good progress, 
but I cannot find one. 

I am not too concerned with the failing rebuild, I would prefer not
to spend time on the older release. But if needed I'll do it.

Well, I will work on oyranos 1.7 (with elektra 6.10) and update to 1.8 (along
with elektra 7. if possible).

So to sum-up (and I will need a reviewer advice for this). 
Since some profiles may still problematic. I would rip off all icc profiles from
oyranos and provides each profiles as a separate requirement for oyranos.

I would package them as:
color-icc-profiles-cineon GPL/BSD ?
color-icc-profiles-lcmsLAB Public Domain
color-icc-profiles-sRGB 
color-icc-profiles-PhotoGamutRGB (tell about Creatives Commons but not strong in
deutch).
colot-icc-profiles-LStarRGB (License need to be clarified but at least
specifications are here for recreate them).

Thoses profiles might be acceptables for Fedora. and as more profiles are
present, they migh be added to a virtual provides,like
color-icc-profiles-all
I don't know if oyranos should Requires all profiles, but at least it can
requires some, so it will work without complain at runtime.

For the oyranos-monitor-nvidia: I will split off from the main package, and I
will rename oyranos-monitor to oyranos-monitor-main, so when
oyranos-monitor-nvidia will be installed, it will be used instead of the main
oyranos-monitor (using alternatives).

About oyranos_version.h, i will rip out OY_SRCDIR and OY_SRC_LOCALEDIR and keep
the timestramps from a reference file. (I wonder if this file should be used
anyway).

(In reply to comment #22)

> So to sum-up (and I will need a reviewer advice for this). 
> Since some profiles may still problematic. I would rip off all icc profiles from
> oyranos and provides each profiles as a separate requirement for oyranos.
> 
> I would package them as:
> color-icc-profiles-cineon GPL/BSD ?
> color-icc-profiles-lcmsLAB Public Domain
> color-icc-profiles-sRGB 
> color-icc-profiles-PhotoGamutRGB (tell about Creatives Commons but not strong in
> deutch).
> colot-icc-profiles-LStarRGB (License need to be clarified but at least
> specifications are here for recreate them).

Why don't you package the profiles that are acceptable in fedora
in oyranos itself? Because they may be needed by other applications?
Because they have separate upstreams?

> Thoses profiles might be acceptables for Fedora. and as more profiles are
> present, they migh be added to a virtual provides,like
> color-icc-profiles-all
> I don't know if oyranos should Requires all profiles, but at least it can
> requires some, so it will work without complain at runtime.

It should certainly requires all the profiles that can be shipped in 
fedora.

> For the oyranos-monitor-nvidia: I will split off from the main package, and I
> will rename oyranos-monitor to oyranos-monitor-main, so when
> oyranos-monitor-nvidia will be installed, it will be used instead of the main
> oyranos-monitor (using alternatives).

That seems quite complicated. In any case a documentation, even minimal,
of oyranos-monitor-nvidia and oyranos-monitor is missing.

On the same subject, the  oyranos-config-fltk man page should be in 
the main package.

> About oyranos_version.h, i will rip out OY_SRCDIR and OY_SRC_LOCALEDIR and keep
> the timestramps from a reference file. (I wonder if this file should be used
> anyway).

It is not clear, indeed. It is a bit dubious to have all these 
symbols defined in the API. The API should be platform independent 
and it is clearly not the case here. There should be no file
name separator in the API, for example.



There are 2 rpmlint warnings relevant for -devel:
oyranos-devel.i386: E: zero-length
/usr/share/doc/oyranos-devel-0.1.7/html/structoyComp__s____coll__graph.map

This one is a bit strange, maybe doxygen is doing wrong things with maps
since there is a reference in the html to oyComp__s____coll__map

oyranos-devel.i386: W: file-not-utf8 /usr/share/doc/oyranos-devel-0.1.7/ChangeLog

Spec URL:
http://kwizart.fedorapeople.org/SPECS/oyranos.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/oyranos-0.1.7-9.fc8.kwizart.src.rpm
Description: The Oyranos Colour Management System (CMS)


changelog
- Comment out the oyranos default policy until some profiles
  are available within the repository.
- Add Requirement needed by oyranos_moni.pc
- Add README-Fedora-ICC_PROFILES
- Uses color-filesystem BR and macros
- Split the doc
- Fix wrong file encoding not-utf8 ChangeLog
- Tweak oyranos_version.h
- Repackage the sources.

In my view, the icc profiles need to be noarch (without a dist tag). With one
packages for one different archive (and upstream), So i'm still working to have
them packaged, then required at runtime with a virtual provides
(color-icc-profiles).

I still have the  oyranos-docs.x86_64: E: zero-length
/usr/share/doc/oyranos-docs-0.1.7/structoyComp__s____coll__graph.map
What seems safer ? do delete it and try to have a file not found error, or can i
leave it for now ?

Removing FE-Legal, okay as GPLv2+

For 0.1.7-9:

* Requires:
  - Would you explain why -devel subpackage "Requires" color-filesystem?

* From build.log:
------------------------------------------------------------------
   901  /builddir/build/BUILD/oyranos-0.1.7/oyranos_monitor.c:1386: Warning: The
following parameters of oyGetDisplayNameFromPosition(const char *display_name,
int x, int y, oyAllocFunc_t allocate_func) are not documented:
   902    parameter display_name
   903  sh: dot: command not found
   904  Problems running dot: exit code=127, command='dot',
arguments='"structoyComp__s____coll__graph.dot" -Tpng -o
"structoyComp__s____coll__graph.png"'
   905  /builddir/build/BUILD/oyranos-0.1.7/oyranos_config.h:41: Warning: Found
unknown command `\autor'
   906  /builddir/build/BUILD/oyranos-0.1.7/oyranos_config.h:65: Warning: Found
unknown command `\autor'
   907  sh: dot: command not found
   908  Problems running dot: exit code=127, command='dot',
arguments='"graph_legend.dot" -Tpng -o "graph_legend.png"'
------------------------------------------------------------------
  - Perhaps graphviz is missing from BuildRequires (as you create document
    files by doxygen).

* Mandir
  - From spec file:
------------------------------------------------------------------
mv $RPM_BUILD_ROOT%{_mandir}/man1/oyranos-config.1
$RPM_BUILD_ROOT%{_mandir}/man3/oyranos-config.3
------------------------------------------------------------------
    Well, moving -config man file to section 3 is correct, however
    this also requires to fix man file itself. Currently
    "man oyranos-config" shows the section is 1.

* Comment on %scriptlet part
------------------------------------------------------------------
%post 
#if [ "`elektra-kdb ls system/sw/oyranos 2>/dev/zero | wc -l`" -eq 0 ]; then
#  oyranos-policy %{_settingscolordir}/office.policy.xml
#fi || :
------------------------------------------------------------------
  - Then "rpm -q --scripts oyranos" shows this, which is not desirable
    because this actually executes a /bin/sh script file (with all comments)
    needlessly. The correct method is to put this part in %if macro like:
------------------------------------------------------------------
%if 0
%post
......
%endif
------------------------------------------------------------------

* Directory ownership issue
  - On my system:
------------------------------------------------------------------
[tasaka1@localhost ~]$ LANG=C rpm -qf /usr/share/color/settings/office.policy.xml 
oyranos-0.1.7-9.fc9.i386
[tasaka1@localhost ~]$ LANG=C rpm -qf /usr/share/color/settings/
file /usr/share/color/settings is not owned by any package
------------------------------------------------------------------

! Multilib conflict
  - From configure:
------------------------------------------------------------------
   584  test -n "$ECHO" && $ECHO "sbindir=$sbindir" >> $CONF_SH
   585  test -n "$ECHO" && $ECHO "libdir=$libdir" >> $CONF_SH
   586  test -n "$ECHO" && $ECHO "includedir=$includedir" >> $CONF_SH
------------------------------------------------------------------
   (here $CONF_SH is oyranos-config) This configure part creates
   oyranos-config different between 32 bits arch vs 64 bits arch.

   For scripts installed under %_bindir and packaged in -devel package,
   this multilib conflict is not allowed.
   * Please check
     http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
     and try to fix this multilib conflict.
   * Or if you feel fixing configure is not easy, you can
     - move oyranos-config to oyranos-config-{32,64} according to
       the architecture
     - Then install oyranos-config as:
-------------------------------------------------------------------
#!/bin/sh
ARCH=$(uname -s)

case $ARCH in
	x86_64 | ia64 | s390 )
	exec oyranos-config-64 $*
	;;
	* )
	exec oyranos-config-32 $*
	;;
esac
-------------------------------------------------------------------
       for example (I guess this work).

Spec URL:
http://kwizart.fedorapeople.org/SPECS/oyranos.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/oyranos-0.1.7-10.fc8.kwizart.src.rpm
Description: The Oyranos Colour Management System (CMS)

Changelog
- Comment out %%post with %%if 0
- Add BR graphviz
- Upate Doxygen before generation (-u) 
  (set CLASS_GRAPH and COLLABORATION_GRAPH to NO )
- Remove Requires color-filesystem for -devel
- Rename man1 to man3 within man pages.

The directory ownership issue have been fixed within the color-filesystem
package. I think that the name is enought generic to be commonly shared (even if
for now, only oyranos will use this directory). Also this concern "default data
setting" not targetted to be modifyed from this directory (once imported in the
elektra registry, they can be modified system wide or by users).

I have also improved the fix_bash patch to remove libdir value within
oyrano-config,so they might be the same (and same timestramps) for both arches.
rebuild of cinepaint went fine with this.

Well, almost okay, however
(In reply to comment #27)
> I have also improved the fix_bash patch to remove libdir value within
> oyrano-config,so they might be the same (and same timestramps) for both arches.
> rebuild of cinepaint went fine with this.

The problem with this is that $libdir is still used in oyranos-config like
(on i386, for example)
--------------------------------------------------------------------------
    33  if [ -n "$PKG_CONFIG_PATH" ]; then
    34    PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$libdir/pkgconfig
    35  else
    36    PKG_CONFIG_PATH=$libdir/pkgconfig
    37  fi
(and some other places)
---------------------------------------------------------------------------
and removing all these $libdir seems not easy.

But for now it works and the only occurence of libdir is for linking time.
As both icc_examin and cinepaint use others package while linking to oyranos,
this lead to something like:
-----------------------
/bin/sh ../../libtool --mode=link --tag=CXX g++
-DLOCALEDIR=\""/usr/share/locale"\"  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic  
-o pdf  pdf.o pdf_dialog.o ../../lib/libcinepaint.la -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0    ../../lib/fl_i18n/libcinepaint_fl_i18n.la
-L/usr/lib64 -lfltk_images -lpng -lz -ljpeg -lfltk -DHAVE_OY -L -loyranos
-loyranos_moni  -ldl -lc
-----------------------
So the empty -L isn't failing as it take the -L/usr/lib64 from others packages.

Well i don't knwo. it remains dirty and the only way to do this would be to use
a pkg-config generated from autotools... But next oyranos 0.1.8 will have a
different scheme so it would be better to have a full autotools support written
from scratch...

(In reply to comment #29)
> But for now it works and the only occurence of libdir is for linking time.
> As both icc_examin and cinepaint use others package while linking to oyranos,
> this lead to something like:
> -----------------------
> /bin/sh ../../libtool --mode=link --tag=CXX g++
> -DLOCALEDIR=\""/usr/share/locale"\"  -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic  
> -o pdf  pdf.o pdf_dialog.o ../../lib/libcinepaint.la -lgtk-x11-2.0
-lgdk-x11-2.0> -latk-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lpango-1.0 -lcairo
-lgobject-2.0
> -lgmodule-2.0 -ldl -lglib-2.0    ../../lib/fl_i18n/libcinepaint_fl_i18n.la
> -L/usr/lib64 -lfltk_images -lpng -lz -ljpeg -lfltk -DHAVE_OY -L -loyranos
> -loyranos_moni  -ldl -lc
> -----------------------
> So the empty -L isn't failing as it take the -L/usr/lib64 from others packages.

(Note: -L/usr/lib64 is always unneeded because /usr/lib64 is in
        default search path of libraries)

This didn't fail fortunately because this file actually didn't need
liboyranos.so (-loyranos).
Try: TEMP.c as
------------------------------------------------------------------------
#include <png.h>

int main(){
	png_sig_cmp(0, 0, 0);
	return 0;
}
-------------------------------------------------------------------------
and
-------------------------------------------------------------------------
[tasaka1@localhost TEMP]$ LANG=C gcc -o TEMP__ TEMP.c -lpng
[tasaka1@localhost TEMP]$ LANG=C gcc -o TEMP__ TEMP.c -L -lpng
/tmp/ccuLIQFO.o: In function `main':
TEMP.c:(.text+0x29): undefined reference to `png_sig_cmp'
collect2: ld returned 1 exit status
--------------------------------------------------------------------------

So would you try tricks written on
http://fedoraproject.org/wiki/PackagingDrafts/MultilibTricks
or what I said on comment 26?

Spec URL:
http://kwizart.fedorapeople.org/SPECS/oyranos.spec
SRPM URL:
http://kwizart.fedorapeople.org/SRPMS/oyranos-0.1.7-11.fc8.kwizart.src.rpm
Description: The Oyranos Colour Management System (CMS)

Changelog
- Make oyranos-config a wrapper for pkgconfig

As oyranos-config are now the same from lib or lib64 (and have the same
timestramps). I would prefer to use it as a wrapper for pkg-config until
oyranos.pc can support all the functions requested to oyranos-config.

For 0.1.7-11:

* -libs dependency
  - Oops, I don't know why I could not notice this before,
    but the correct dependency is that main (oyranos) rpm
    should have "Requires: %{name}-libs = %{version}-%{release}"
    and -libs subpackage should not have "Requires: %{name}
    = ...."

Other things are okay.
----------------------------------------------------------------
    This package (oyranos) is APPROVED by me
----------------------------------------------------------------

I can do that, but cinepaint will need to requires oyranos then
(it use /usr/bin/oyranos-config-fltk )

Well i will do that before importing. It will make oyranos requirement to be
found more easily as i expect.

Thx 

New Package CVS Request
=======================
Package Name: oyranos
Short Description: The Oyranos Colour Management System (CMS)
Owners: kwizart
Branches: F-8
Cvsextras Commits: yes

cvs done.