Bug 189717

I've had contact with upstream and the 2 small known issues have been fixed
upstream, I'll see if its easy to backport the fixes.

I've updated both the spec file ant he -files.tar.gz with a -2 version, this
fixes issue 1) unfortunatly upstreams fix for issue 2) was not correct / did not
fix the issue.

* rpmlint warnings:
W: gcompris incoherent-version-in-changelog 7.4-2 7.4-1
W: gcompris-devel no-dependency-on gcompris
...plus some 'no documentation' warnings that you might be able to ignore.

* gcompris-desktop.patch has the following line that should probably be removed:
Only in gcompris-7.4: gcompris.desktop.in~

* Only builds on the devel branch due to missing libassetml for FC-5.

* The icon in the .desktop files are missing the .png extension, but the icons
in the icon directory end in .png.

I'm looking at gnucap now, so I'll probably have more comments once I can
actually install this.

(In reply to comment #3)
> * rpmlint warnings:
> W: gcompris incoherent-version-in-changelog 7.4-2 7.4-1

My bad I added a changelog entry for my changes but forgot to bump Release: I
will fix this (easy).

> W: gcompris-devel no-dependency-on gcompris

Thats because it depends on gcompris-libs, where the actual libs are thats what
you get with program and libs (and data) in one _big_ upstream tarbal.

> ...plus some 'no documentation' warnings that you might be able to ignore.
> 

gcompris comes with plenty of documentation in the main package in a lot of
languages, so yes I intend to ignore these :)

> * gcompris-desktop.patch has the following line that should probably be removed:
> Only in gcompris-7.4: gcompris.desktop.in~
> 

Thats because I used diff not gendiff to generate the diff, this is totaly
harmless, but I can remove it if it makes you happy.

> * Only builds on the devel branch due to missing libassetml for FC-5.
> 

My grand master plan was / is to ask for a FC-5 cvs branch for libassetml,
gnucap and gcompris all at the same time.

> * The icon in the .desktop files are missing the .png extension, but the icons
> in the icon directory end in .png.
> 

Other .desktop files have this too (gsview for example) it works fine either
way,but my desktop patch did screw up the .desktop translations, so I have to
fix that anyways, I can also add the .png at the same time if you want, but that
would be unnescesarry deviation from upstream.

Created attachment 128297 [details]
improved specfile

Here is an improved specfile, this fixes the changelog <-> version warning.
I've dropped the desktop.in patch as that breaks .desktop file translations and
replaced this with 2 sed commands, which are run at the end of %build, thus
after the translations have been merged into the desktop files. It turns out
that the upstream .desktop files do have .png at the end for the icons, and I
no longer remove this :)

I've just finished uploading a new version, locations are still the same:
Spec URL:  http://home.zonnet.nl/jwrdegoede/gcompris.spec
Files URL: http://home.zonnet.nl/jwrdegoede/gcompris-files.tar.gz

Notting was changed except for the addition of Patch4 which fixes issue 2) as
listed in the initial opening comment.

rpmlint output:
E: gcompris hardcoded-library-path in $RPM_BUILD_ROOT/usr/lib/menu

- This is a bogus warning.  rpmlint is complaining about the src
  rpm without realizing that this file is being removed, not included.

W: gcompris-devel no-dependency-on gcompris

- This is ok by design.  -devel requires -libs so that it doesn't
  need to pull in rather large (and unnecessary) base package.

W: gcompris-devel no-documentation
W: gcompris-libs no-documentation

- This can be ignored.  The developers documentation is integrated with
  the base package's documentation.

W: gcompris-flags no-documentation
W: gcompris-sound-da no-documentation
W: gcompris-sound-de no-documentation
W: gcompris-sound-en no-documentation
W: gcompris-sound-es no-documentation
W: gcompris-sound-eu no-documentation
W: gcompris-sound-fi no-documentation
W: gcompris-sound-fr no-documentation
W: gcompris-sound-hu no-documentation
W: gcompris-sound-it no-documentation
W: gcompris-sound-nl no-documentation
W: gcompris-sound-pt no-documentation
W: gcompris-sound-ru no-documentation
W: gcompris-sound-sv no-documentation

- These can be ignored.  There's no need for documentation for localized
  sound/flag files.


MUST
====
 * GPL license ok, license file included
 * Package and spec file named appropriately
 * Spec file legible and in Am. English (except for the localized parts)
 * Sources for the review came from upstream:
   d80e55da21170a98d671c98b3e582cc3  SOURCES/gcompris-7.4.tar.gz
 * Builds in mock on devel-i386, devel-x86_64
 * Locales handled appropriately
 * ldconfig called for shared libs in -libs subpackage
 * Not relocatable
 * Owns directories that it creates
 * No duplicate %files
 * Contains code and permissible content
 * $RPM_BUILD_ROOT cleaned correctly in %install and %clean
 * File permissions appear to be ok
 * headers, .so, and pkgconfig files in -devel
 * -devel requires -libs, not base (this is acceptable, see above)
 * .la files not included
 * .desktop files installed correctly
 * No need for -doc subpackage

SHOULD
=========
 * Consider adding Requires: tuxpaint for the tuxpaint launcher

I did a quick check of the english/german sounds on a handful of the games and
it worked with no obvious problems.

No blockers found.

APPROVED

(In reply to comment #7)
> 
> SHOULD
> =========
>  * Consider adding Requires: tuxpaint for the tuxpaint launcher
>

Ah, I thought they had build their own clone / copy I didn'y know it was just a
launcher, I've added the requirement.
 
> I did a quick check of the english/german sounds on a handful of the games and
> it worked with no obvious problems.
> 

I may hope so this one has taken me a lot of time :)

> No blockers found.
> 
> APPROVED
> 

Thanks!

Imported & Build.

Hello, it is possible to make packages for EL7 ?
THANKS

Hi,

(In reply to PM from comment #9)
> Hello, it is possible to make packages for EL7 ?
> THANKS

I'm sorry, but I don't have the time to maintain EPEL packagers, if you're a packager yourself, you're welcome to request and maintain EPEL branches of gcompris. If you're not a packager yourself, try asking someone who maintains EPEL packages.

Regards,

Hans