Bug 526444

Uhh, the summary "Fast, simple and flexible GUI" is a *bit* too generic, change it to e.g. "Fast, simple and flexible GUI for Ogre".

Why are you using the SVN release instead of the stable one?

(In reply to comment #1)
> Uhh, the summary "Fast, simple and flexible GUI" is a *bit* too generic, change
> it to e.g. "Fast, simple and flexible GUI for Ogre".
> 

Sounds right; i swear if i also had to name the package ogre-mygui: it's not actually an addon (libs go to _libdir not _libdir/OGRE), but is of no use without it. 

> Why are you using the SVN release instead of the stable one?  

I'm targeting that specific revision (with minor changes ahead of the released 2.2.2) because its a dependency of http://dungeonhack.sourceforge.net, an ogre game i plan to package in the near future.

Updated package with changed summary and a couple of helper scripts which i forgot to include in the previous one.

Spec URL: 
http://guidograzioli.fedorapeople.org/packages/mygui/mygui.spec
SRPM URL:
http://guidograzioli.fedorapeople.org/packages/mygui/mygui-2.3.0-2.1861svn.fc11.src.rpm

I also launched a koji build, here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1721377

Trying to build your package here to get rpmlint output for the packages built and rpmlint for the installed packages:

[thomas@tusdell SPECS]$ rpmbuild -ba mygui.spec
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.naOtPu
+ umask 022
+ cd /home/thomas/rpmbuild/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /home/thomas/rpmbuild/BUILD
+ rm -rf mygui
+ @__XZ@ -dc /home/thomas/rpmbuild/SOURCES/mygui-2.3.0-1861svn.tar.xz
/var/tmp/rpm-tmp.naOtPu: line 29: @__XZ@: command not found
+ /bin/tar -xf -
/bin/tar: This does not look like a tar archive
/bin/tar: Error exit delayed from previous errors
error: Bad exit status from /var/tmp/rpm-tmp.naOtPu (%prep)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.naOtPu (%prep)
-------------------------------------------

[root@tusdell thomas]# rpm -q xz
xz-4.999.8-0.8.beta.20090817git.fc10.x86_64

I guess there's a reason why you use xz over gz.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

(In reply to comment #4)
> Trying to build your package here to get rpmlint output for the packages built
> and rpmlint for the installed packages:
> 
> [thomas@tusdell SPECS]$ rpmbuild -ba mygui.spec
> /var/tmp/rpm-tmp.naOtPu: line 29: @__XZ@: command not found

xz is not enough to build using xz, you need rpm-4.6.1-2 for F-10 which currently is in update-testing (see bug 514480). Build against F-11 or rawhide is fine (see koji build above).

> 
> I guess there's a reason why you use xz over gz.
> 


Yep, that's why:
-rw-rw-r--. 1 guido guido 5583126 2009-10-03 20:50 mygui-2.3.0-1861svn.tar.gz
-rw-rw-r--. 1 guido guido 3910552 2009-09-28 20:45 mygui-2.3.0-1861svn.tar.xz

And for coherency because of:
http://fedoraproject.org/wiki/Features/XZRpmPayloads

Thanks for looking into this

Just for the record ;)
# rpm -q rpm
rpm-4.6.1-2.fc10.x86_64

Koji scratch build dist F10 from your SRPM
http://koji.fedoraproject.org/koji/taskinfo?taskID=1726120

MUST: rpmlint must be run on every package. The output should be posted in the review.
Please run it on the installed packages as well. Saves me the time to build it on another box.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

If you target dist-f10 in koji or mock, you dont get 4.6.1-2 but 4.6.1-1:
[...]
DEBUG util.py:256:  Installed:
DEBUG util.py:256:    patch.i386 0:2.5.4-35.fc10          redhat-rpm-config.noarch 0:9.0.3-7.fc10   
DEBUG util.py:256:    rpm-build.i386 0:4.6.1-1.fc10       sed.i386 0:4.1.5-11.fc10                  
[...]
DEBUG util.py:256:  Dependency Installed:
[...]
DEBUG util.py:256:    rpm.i386 0:4.6.1-1.fc10
DEBUG util.py:256:    rpm-libs.i386 0:4.6.1-1.fc10            
[...]

However, if you cant build with F-10 and 4.6.1-2, it means the bug isn't fixed yet; for the sole purpose to test against rpmlint please consider downloading koji generated rpms built here for dist-f12:
http://koji.fedoraproject.org/koji/taskinfo?taskID=1721377
or running yourself a build against dist-f12.

Anyway, i will only request devel and F-11 (and F-12) branches for this one; thanks.

Some comments, most are cosmetic :)

(In reply to comment #2)
> I'm targeting that specific revision (with minor changes ahead of the released
> 2.2.2) because its a dependency of http://dungeonhack.sourceforge.net, an ogre
> game i plan to package in the near future.  
2.2.3 was released some time ago, I think best would be package either latest release or latest revision from svn.

> Boost license used in MyGUI_Any.h
> License:        LGPLv3+ and Boost
They “wrapped” boost license in this header with LGPL, so no need to specify boost license separately.

> Summary:        Mygui demo executables and media
May be, call it “MyGUI” in summary?

> # Strip away unittests media and a code sample in media dir
> rm -rf %{buildroot}%{_datadir}/MYGUI/Media/Tools/LayoutEditor/CodeTemplates/
Are you sure that this is not used in generating layout? I can't check it right now. 

> %package        devel
> Requires:       pkgconfig, ois-devel
May be require ogre-devel too? 

> %doc Readme.txt
This is some compilation instructions - no need to include.

May be split devel documentation in devel-doc subpackage?

And, please, split changelog entries by empty line.

(In reply to comment #8)
> Some comments, most are cosmetic :)
> 

I'm working on your suggestions, the only one i cannot face at the moment is the update to upstream trunk. They changed their build system to cmake, and are having a lot of mess in it (problems with multilib, library detection, some errors in the scripts). I worked for some time on an updated spec to trunk, but after i realized there were too many troubles and workarounds needed i gave up.  I think its better to stick with current chosen revision (or go ahead a bit, but before the switch to cmake), till things get steadier.

I will post an updated srpm asap, sorry Thomas if you were working on the review, you'll have some extra work.

They seem not to use cmake in 2.2.3 - may be update to that version?

Ok, sooner or later the work to port the spec to cmake had to be done, so better doing it through the review process. After working some more on it, i could successfully build trunk, but i still have some rpmlint complaints.

Updated files:
http://guidograzioli.fedorapeople.org/packages/mygui/mygui.spec
http://guidograzioli.fedorapeople.org/packages/mygui/mygui-3.0.0-1.2332svn.fc11.src.rpm

Changelog:
* Fri Oct 13 2009 Guido Grazioli <guido.grazioli> - 3.0.0-1.2332svn
- Upstream to svn revision 2332
- Patch cmake build scripts to support multilib
- Fix package summaries
- Fix changelog
- Fix %%doc
- Add Require: ogre-devel to -devel subpackage
- Add -devel-doc subpackage
- Revert source tarball from xz to bzip2

Rpmlint:

* mygui.x86_64: E: invalid-soname /usr/lib64/libPlugin_StrangeButton.so.3.0.0 libPlugin_StrangeButton.so
- It is a plugin shlib (plugins are custom widgets), i dont understand this one

* mygui.x86_64: W: dangling-symlink /usr/share/MyGUI/Media/MyGUI_Media/DejaVuSans-ExtraLight.ttf /usr/share/fonts/dejavu/DejaVuSans-ExtraLight.ttf
* mygui.x86_64: W: dangling-symlink /usr/share/MyGUI/Media/MyGUI_Media/DejaVuSans.ttf /usr/share/fonts/dejavu/DejaVuSans.ttf
- I linked the font from the rpm package and i included the rpm among Requires, should i use a file based require?

* mygui-devel.x86_64: W: no-documentation
- Doxygen doc went to -devel-doc i think this can be ignored

* mygui-tools.x86_64: W: devel-file-in-non-devel-package /usr/share/MyGUI/Media/Tools/LayoutEditor/CodeTemplates/BaseLayoutCPP/BaseLayoutTemplate.cpp
* mygui-tools.x86_64: W: devel-file-in-non-devel-package /usr/share/MyGUI/Media/Tools/LayoutEditor/CodeTemplates/BaseLayoutCPP/BaseLayoutTemplate.h
- Those are code templates for code generation, where should they go?

Give it any news here?

I'll be trying to help with the packages needed for dungeonhack.

Hello, i've made some more work to improve this package:

- fix building with cmake  
- manually install missing library libMyGUI.OgrePlatform.so
- create /etc/ld.so.conf.d/mygui.conf to add /usr/{libdir}/MYGUI to ldconfig
- remove -msse from flags (to let it build on ppc/ppc64)
- remove plugins (actually there was just one plugin) because they need work upstream to work on unix
- fix include dir 
- fix wrapper scripts to use new resources.xml instead of resources.cfg

Updated files here:
http://guidograzioli.fedorapeople.org/packages/mygui/

Koji build here: 
http://koji.fedoraproject.org/koji/taskinfo?taskID=1781251

Rpmlint, the package still has warnings:
mygui.x86_64: W: dangling-symlink (2 font files)
mygui-devel.x86_64: W: no-documentation
mygui-tools.x86_64: W: devel-file-in-non-devel-package (3 code template files used by LayoutEditor tool)

[fix]
Release should be: 0.2.2332svn%{?dist}
So you get a 3.0.0-0.2.2332svn package

http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Release

[fix]
You use a mix of $RPM_BUILD_ROOT and %{buildroot}

[fix]
You use %cmake but no macro for the rest of the commands like install, sed. 

[fix]
No need for VERBOSE=1 in %build

I rebuilt it here and it was running after i installed mygui and mygui-tools (i tried the LayoutEditor).
Does it make sense to have mygui installed alone? Can one do anything with it, without the tools?
If not, make the tools installed with the mainpackage, or maybe merge the tool package into the main package.

As well it couldn't load anything from the list (within the load dialog). Maybe just me.

Are the code template files needed outside a develpackage? Does the program work without them installed? You could move them into the devel package and make that installed by default as well.

[fix]
rpmlint -I dangling-symlink
dangling-symlink:
The target of the symbolic link does not exist within this package or its file
based dependencies.  Verify spelling of the link target and that the target is
included in a package in this package's dependency chain.

[fix]
rpmlint from installed packages:

mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0 dlsym
mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0 uuid_generate
mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0 dlopen
mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0 dlcloserpmlint -I undefined-non-weak-symbol

undefined-non-weak-symbol:
The binary contains undefined non-weak symbols.  This may indicate improper
linkage; check that the binary has been linked as expected.

You might check that linking problem with upstream.

(In reply to comment #15)
> [fix]
> Release should be: 0.2.2332svn%{?dist}
> So you get a 3.0.0-0.2.2332svn package
> 
> http://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Release
> 
> [fix]
> You use a mix of $RPM_BUILD_ROOT and %{buildroot}
> 
> [fix]
> No need for VERBOSE=1 in %build
> 

Ok, i'm working on the above issues.

> [fix]
> You use %cmake but no macro for the rest of the commands like install, sed. 
> 

I have seen use of core commands without macros in other packages; are macros mandatory? %cmake does a lot of things while %install and %sed are just wrappers 


> I rebuilt it here and it was running after i installed mygui and mygui-tools (i
> tried the LayoutEditor).
> Does it make sense to have mygui installed alone? Can one do anything with it,
> without the tools?
> If not, make the tools installed with the mainpackage, or maybe merge the tool
> package into the main package.

MyGUI is a library that allows to build UIs defined with xml files, so yes, i think most installations will only involve the main package. The LayoutEditor is a (ongoing development) tool to help create those xml files, helping developers in designing uis. I could require -devel for the -tools to render that explicit, even if the tools works alone. Please share your thoughts.

> As well it couldn't load anything from the list (within the load dialog). 
> Maybe just me.

The current file dialog doesnt filter out unsupported files, and the working directory is a dotdir that contains some other files needed to run the editor. Can you please report if saving a simple design (a window with a button for instance), closing the editor, then loading it again works? 

> Are the code template files needed outside a develpackage? Does the program
> work without them installed? You could move them into the devel package and
> make that installed by default as well.

The templates are meant for code generation by LayoutEditor, that's why they included them in Media subdirectory; note that code generation is not in LayoutEditor yet. atm LayoutEditor will work without them, but i included those files here to pass under the review process. I can only add that suse folks have packaged the templates in {_datadir} as well.

> [fix]
> rpmlint -I dangling-symlink
> dangling-symlink:
> The target of the symbolic link does not exist within this package or its file
> based dependencies.  Verify spelling of the link target and that the target is
> included in a package in this package's dependency chain.

Need help here; the two fonts linked are provided by package dejavu-sans-fonts, which is among requires. After installation, the symlinks are working. Should i add a file based require? Adding BRs is not enough to make warning go away.

> [fix]
> rpmlint from installed packages:
> 
> mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0
> dlsym
> mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0
> uuid_generate
> mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0
> dlopen
> mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0
> dlcloserpmlint -I undefined-non-weak-symbol
> 
> undefined-non-weak-symbol:
> The binary contains undefined non-weak symbols.  This may indicate improper
> linkage; check that the binary has been linked as expected.
> 
> You might check that linking problem with upstream.  

ok, i'm not on rawhide and my rpmlint wasnt reporting those warnings, i will investigate the problem.

(In reply to comment #16)
> (In reply to comment #15)

> > [fix]
> > You use %cmake but no macro for the rest of the commands like install, sed. 
> > 
> 
> I have seen use of core commands without macros in other packages; are macros
> mandatory? %cmake does a lot of things while %install and %sed are just
> wrappers 
 
Just saying, use macros, or not :) Consistency.
 
> > I rebuilt it here and it was running after i installed mygui and mygui-tools (i
> > tried the LayoutEditor).
> > Does it make sense to have mygui installed alone? Can one do anything with it,
> > without the tools?
> > If not, make the tools installed with the mainpackage, or maybe merge the tool
> > package into the main package.
> 
> MyGUI is a library that allows to build UIs defined with xml files, so yes, i
> think most installations will only involve the main package. The LayoutEditor
> is a (ongoing development) tool to help create those xml files, helping
> developers in designing uis. I could require -devel for the -tools to render
> that explicit, even if the tools works alone. Please share your thoughts.

Hmm.. Ok, then the %description of the main and -tools package are confusing.

Summary:        Fast, simple and flexible GUI for Ogre  <== shouldn't that be library instead of GUI? Or gui creator

%description
MyGUI is a GUI library for Ogre Rendering Engine which aims to be fast, 
flexible and simple in using. 
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^same here

%description    tools
This package contains the GUI tools... <== complete this sentence as you think it would fit best. That way it's obviously there are GUI tools.


That gets me to another point i forgot in the last post. There's no desktop file for the GUI apps. Means nothing shows up here in my menu (KDE menu with search function). I was able to start it via terminal/krunner.

You should add desktop files for the GUI apps. To find out how this works isn't very user friendly (not to blame you). One has to run MyGUI-Tools in a terminal to find out that there are three things he can run.

Would be great from my point of view to have .desktop files to start it from the menu.
 
> > As well it couldn't load anything from the list (within the load dialog). 
> > Maybe just me.
> 
> The current file dialog doesnt filter out unsupported files, and the working
> directory is a dotdir that contains some other files needed to run the editor.
> Can you please report if saving a simple design (a window with a button for
> instance), closing the editor, then loading it again works? 

Yes it does work, sorry, haven't thought about that.

> > Are the code template files needed outside a develpackage? Does the program
> > work without them installed? You could move them into the devel package and
> > make that installed by default as well.
> 
> The templates are meant for code generation by LayoutEditor, that's why they
> included them in Media subdirectory; note that code generation is not in
> LayoutEditor yet. atm LayoutEditor will work without them, but i included those
> files here to pass under the review process. I can only add that suse folks
> have packaged the templates in {_datadir} as well.

Ok. To have the templates in %{_datadir} isn't the problem. I was just asking because of the rpmlint warnings about the devel files.
Package the devel files (code templates) into the -devel package and make the -tools package require the -devel package installed.

> > [fix]
> > rpmlint -I dangling-symlink
> > dangling-symlink:
> > The target of the symbolic link does not exist within this package or its file
> > based dependencies.  Verify spelling of the link target and that the target is
> > included in a package in this package's dependency chain.
> 
> Need help here; the two fonts linked are provided by package dejavu-sans-fonts,
> which is among requires. After installation, the symlinks are working. Should i
> add a file based require? Adding BRs is not enough to make warning go away.

Hmm.. I have to digg deeper into that as well. Looking at my last paste (at bottom) you can see the warning is after it's installed.

> > [fix]
> > rpmlint from installed packages:
> > 
> > mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0
> > dlsym
> > mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0
> > uuid_generate
> > mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0
> > dlopen
> > mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0
> > dlcloserpmlint -I undefined-non-weak-symbol
> > 
> > undefined-non-weak-symbol:
> > The binary contains undefined non-weak symbols.  This may indicate improper
> > linkage; check that the binary has been linked as expected.
> > 
> > You might check that linking problem with upstream.  
> 
> ok, i'm not on rawhide and my rpmlint wasnt reporting those warnings, i will
> investigate the problem.  

You get those rpmlint output running rpmlint on the installed packages:

[thomas@tusdell ~]$ rpmlint mygui mygui-tools mygui-devel mygui-demos mygui-debuginfo
mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0 dlsym
mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0 uuid_generate
mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0 dlopen
mygui.x86_64: W: undefined-non-weak-symbol /usr/lib64/libMyGUIEngine.so.3.0.0 dlclose
mygui.x86_64: W: dangling-symlink /usr/share/MyGUI/Media/MyGUI_Media/DejaVuSans-ExtraLight.ttf /usr/share/fonts/dejavu/DejaVuSans-ExtraLight.ttf
mygui.x86_64: W: dangling-symlink /usr/share/MyGUI/Media/MyGUI_Media/DejaVuSans.ttf /usr/share/fonts/dejavu/DejaVuSans.ttf
mygui-tools.x86_64: W: devel-file-in-non-devel-package /usr/share/MyGUI/Media/Tools/LayoutEditor/CodeTemplates/BaseLayoutCPP/BaseLayoutTemplate.cpp
mygui-tools.x86_64: W: devel-file-in-non-devel-package /usr/share/MyGUI/Media/Tools/LayoutEditor/CodeTemplates/BaseLayoutCPP/BaseLayoutTemplate.h
mygui-tools.x86_64: W: devel-file-in-non-devel-package /usr/share/MyGUI/Media/Tools/LayoutEditor/CodeTemplates/BaseLayoutCPP/EventTemplate.cpp
mygui-devel.x86_64: W: no-documentation
5 packages and 0 specfiles checked; 0 errors, 10 warnings.

I just wanted to point out that there's no requirement at all that you use useless macros like %{__rm} or %{__sed} if you use something required like %configure or %cmake.

(In reply to comment #18)
> I just wanted to point out that there's no requirement at all that you use
> useless macros like %{__rm} or %{__sed} if you use something required like
> %configure or %cmake.  

Looks like i learned it wrong. Thanks for the pointer Jason.

@Guido
Forget the part then, sorry for the cry wolf.

No problem, i'm still learning; about the dangling symlinks, i can confirm that if i add file based requires:
Requires:  %{_datadir}/fonts/dejavu/DejaVuSans.ttf
Requires:  %{_datadir}/fonts/dejavu/DejaVuSans-ExtraLight.ttf
i get no more warnings. I read somewhere in the wiki that adding file based requires is unsafe, am i wrong? Alternatives?

--
About the other warning:

[makerpm@localhost SPECS]$ ldd -d -r /usr/lib64/libMyGUIEngine.so.3.0.0
undefined symbol: dlsym    (/usr/lib64/libMyGUIEngine.so.3.0.0)
undefined symbol: uuid_generate   (/usr/lib64/libMyGUIEngine.so.3.0.0)
undefined symbol: dlopen   (/usr/lib64/libMyGUIEngine.so.3.0.0)
undefined symbol: dlclose  (/usr/lib64/libMyGUIEngine.so.3.0.0)
 linux-vdso.so.1 =>  (0x00007fffa3bff000)
 libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003fe6e00000)
 libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x0000003ff1000000)
 libm.so.6 => /lib64/libm.so.6 (0x0000003fe3600000)
 libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x0000003fed800000)
 libc.so.6 => /lib64/libc.so.6 (0x0000003fe3200000)
 /lib64/ld-linux-x86-64.so.2 (0x0000003fe2c00000)

they miss -ldl, but -luuid is there; can be a problem with the move of uuid.h from e2fsprog-devel to libuuid-devel ? 

--
.desktop files: you have a good point here. In the guidelines we have that each package that contains a gui must have a corresponding desktop entry; however, adding an icon for each demo and each tool - even if in a specific submenu entry - seems chaotic in my opinion. Would it be feasible to add only a desktop entry for LayoutEditor, which is the only really (well, in the future) useful tool? In that case, "Graphics" or "Development"?

-- 
Summaries and descriptions: ok! I just copied some sentences i found in their site, willing to fix them later, but i forgot it..

-- 
Moving code templates to -devel and make -tools require -devel: ok, seems reasonable

(In reply to comment #20)
> No problem, i'm still learning; about the dangling symlinks, i can confirm that
> if i add file based requires:
> Requires:  %{_datadir}/fonts/dejavu/DejaVuSans.ttf
> Requires:  %{_datadir}/fonts/dejavu/DejaVuSans-ExtraLight.ttf
> i get no more warnings. I read somewhere in the wiki that adding file based
> requires is unsafe, am i wrong? Alternatives?

It's not unsafe, but it is not recommended to use file requires since it means that file lists need to be downloaded and resolved to figure out the dependencies.

Just add Requires: dejavu-sans-fonts, which provides both of the aforementioned files.

(In reply to comment #21)
> (In reply to comment #20)
> > No problem, i'm still learning; about the dangling symlinks, i can confirm that
> > if i add file based requires:
> > Requires:  %{_datadir}/fonts/dejavu/DejaVuSans.ttf
> > Requires:  %{_datadir}/fonts/dejavu/DejaVuSans-ExtraLight.ttf
> > i get no more warnings. I read somewhere in the wiki that adding file based
> > requires is unsafe, am i wrong? Alternatives?
> 
> It's not unsafe, but it is not recommended to use file requires since it means
> that file lists need to be downloaded and resolved to figure out the
> dependencies.
> 
> Just add Requires: dejavu-sans-fonts, which provides both of the aforementioned
> files.  

Hmm.. The problem/warning is with already added requires dejavu-sans-fonts and when you run rpmlint on the installed packages.

(In reply to comment #22)
> (In reply to comment #21)
> > Just add Requires: dejavu-sans-fonts, which provides both of the aforementioned
> > files.  
> 
> Hmm.. The problem/warning is with already added requires dejavu-sans-fonts and
> when you run rpmlint on the installed packages.  

If it still complains and the symlinks aren't broken, then it's a false warning. Just ignore it.

OK here are the updated files:

http://guidograzioli.fedorapeople.org/packages/mygui/mygui.spec
http://guidograzioli.fedorapeople.org/packages/mygui/mygui-3.0.0-0.3.2332svn.fc11.src.rpm 


Changelog:
* Wed Nov 18 2009 Guido Grazioli <guido.grazioli> - 3.0.0-0.3.2332svn
- Fix macros usage
- Fix Release tag
- Add desktop entry for LayoutEditor
- Update patch to fix missing undefined non-weak symbols
- Improve summaries and descriptions
- Remove redundant VERBOSE flag
- Add graphviz BR to generate doxygen graphs


Notes:
* W: dangling symlinks ignored
* Move code templates to -devel and make -tools require -devel: unfortunately if i do that, rpmlint complains: 
# rpmlint -i mygui-tools
mygui-tools.x86_64: E: devel-dependency mygui-devel
Your package has a dependency on a devel package but it's not a devel package
itself.
Thus i'm leaving things as they are (getting W: devel-file-in-non-devel-package)

There is a new koji build here: http://koji.fedoraproject.org/koji/taskinfo?taskID=1814631 as well.

Ok. There are some warnings left we can't get rid of.
I still would change the main Summary and get rid of "GUI" there. Or change the sentence that it's clear that this is a library to create/generate GUIs.

Else you fixed all the problems.

APPROVED.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Thanks Thomas for your time; i'm changing the summary as requested upstream, which should reflect your request also.

New Package CVS Request
=======================
Package Name: mygui
Short Description: free cross-platform GUI library for graphics APIs / engines
Owners: guidograzioli
Branches: F-11 F-12 
InitialCC:

cvs done.

mygui-3.0.0-0.4.2332svn.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/mygui-3.0.0-0.4.2332svn.fc11

mygui-3.0.0-0.4.2332svn.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/mygui-3.0.0-0.4.2332svn.fc12

mygui-3.0.0-0.4.2332svn.fc12 has been pushed to the Fedora 12 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mygui'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F12/FEDORA-2009-12805

mygui-3.0.0-0.4.2332svn.fc11 has been pushed to the Fedora 11 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update mygui'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-12853

mygui-3.0.0-0.4.2332svn.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.

mygui-3.0.0-0.4.2332svn.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.