Spec URL: http://people.atrpms.net/~hdegoede/alleggl.spec SRPM URL: http://people.atrpms.net/~hdegoede/alleggl-0.4.0-0.1.rc4.src.rpm Description: AllegroGL is an Allegro add-on that allows you to use OpenGL alongside Allegro. You use OpenGL for your rendering to the screen, and Allegro for miscellaneous tasks like gathering input, doing timers, getting cross-platform portability, loading data, and drawing your textures. So this library fills the same hole that things like glut do. AllegroGL also automatically exposes most, if not all, OpenGL extensions available to user programs. This means you no longer have to manually load them; extension management is already done for you.
Hmm, I just noticed that this installs an autoheader generated header, which is BAD! I'll whip up a fix for this.
New version which has the autoheader stuff fixed here: Spec URL: http://people.atrpms.net/~hdegoede/alleggl.spec SRPM URL: http://people.atrpms.net/~hdegoede/alleggl-0.4.0-0.2.rc4.src.rpm
Created attachment 133604 [details] Build log in mock (failure result) ========== I cannot formally review your package ========== However rebuilding this package in mock fails on i386. See the attachment.
Next time please attach: /var/lib/mock/fedora-development-x86_64-core/root/builddir/build/BUILD/xxx/config.log too when a mock build fails because of a ./configure failure. I've done a mockbuild myself on my painfull slow internet connection and now have this fixed, it was missing BRs for libXext-devel and libXpm-devel. New version here: Spec URL: http://people.atrpms.net/~hdegoede/alleggl.spec SRPM URL: http://people.atrpms.net/~hdegoede/alleggl-0.4.0-0.3.rc4.src.rpm
p.s. I forgot to mention that I'll be on a short vacation till wednesday, so don't expect any response from me till then.
* rpmlint: no problems * Package named correctly: Yes * Patches named correctly: N/A * Spec file named correctly: Yes * Licence field matches: Yes * Licence file installed: No (OK but should query upstream) * Spec file in American English: Yes * Source matches upstream: Yes * Locales use %find_lang: N/A * Contains %clean: Yes * Specfile legible: Yes * Compiles and builds ok: Yes (mock: fc5/ppc) * Calls ldconfig in %post/%postun for shlibs: Yes * Owns directories it creates: Yes * Duplicate files: No * Permission set correctly: Yes * Consistent macro use: Yes * %doc affects runtime: No * Headers and static libs in -devel: Yes * .pc files in -devel: N/A * .so in -devel: Yes * -devel requires base: Yes * Contains .la files: No * Owns files it didn't create: No * .desktop files installed correctly: N/A 1. As it needs allegro >= 4.2.0, i suggest putting a version dependency on allegro-devel for both the base and -devel packages 2. As faq.txt contains information exclusively of interest to developing/ building with alleggl I suggest moving it to -devel 3. readme.txt is primarily build instructions, I suggest excluding it. 4. In -devel, the *.hhk *.hhc and *.hhp files are Microsoft Windows HTML Help files if I remember right, probably of no interesting in Linux, I would exclude them. Otherwise it's cool.
(In reply to comment #6) > 1. As it needs allegro >= 4.2.0, i suggest putting a version dependency on > allegro-devel for both the base and -devel packages > I would rather not, tihs package is targeted soley at FC-5 and higher, so this is not nescesarry. Versioned dependencies IMHO only give a false sense of security, since often they are never updated after the initial specfile creation even if upstreams requirements change. > 2. As faq.txt contains information exclusively of interest to developing/ > building with alleggl I suggest moving it to -devel > I was thinking along the same lines when creating the package, but I wasn't sure since you agree I'll move it to devel. > 3. readme.txt is primarily build instructions, I suggest excluding it. > I was thinking along the same lines (again) when creating the package, but I wasn't sure since you agree I'll remove it. > 4. In -devel, the *.hhk *.hhc and *.hhp files are Microsoft Windows HTML Help > files if I remember right, probably of no interesting in Linux, I would > exclude them. Agreed, done. Thanks for the review!, new version here: Spec URL: http://people.atrpms.net/~hdegoede/alleggl.spec SRPM URL: http://people.atrpms.net/~hdegoede/alleggl-0.4.0-0.4.rc4.src.rpm
> I would rather not, tihs package is targeted soley at FC-5 and higher, so this > is not nescesarry. Versioned dependencies IMHO only give a false sense of > security, since often they are never updated after the initial specfile > creation > even if upstreams requirements change. No problem. I prefer versioned dependencies if the source makes a specific request for a version but for different reasons :) Looks good Hans, Approved!
Thanks! Imported & build, closing.