Bug 194355 - Review Request: imlib
Review Request: imlib
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-06-07 10:30 EDT by Matthias Clasen
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-07-03 19:16:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthias Clasen 2006-06-07 10:30:30 EDT
imlib should move out of Core, together with the rest of
the Gnome 1 stack thats already in Extras. I have not done
any cleanups on the spec file yet, since I am a little short
on time; the linked spec file is the one currently used in
Core.

Spec URL: http://people.redhat.com/review/imlib.spec
SRPM URL: http://people.redhat.com/review/imlib-1.9.13-26.2.1.src.rpm
Description: 
Imlib is a display depth independent image loading and rendering
library. Imlib is designed to simplify and speed up the process of
loading images and obtaining X Window System drawables. Imlib
provides many simple manipulation routines which can be used for
common operations.
Comment 1 Michael J Knox 2006-06-14 15:02:24 EDT
As stated on fedora-extras, I will claim this package for extras. 
Comment 2 Michael J Knox 2006-06-14 15:34:41 EDT
Hey Matthias, the urls do not open :-/ can you recheck them?
Comment 3 Matthias Clasen 2006-06-14 15:37:56 EDT
Hmm, I was sure that I added updated urls here...
oh, bugzilla ate them !

Spec URL: http://people.redhat.com/review/imlib.spec
SRPM URL: http://people.redhat.com/review/imlib-1.9.13-27.src.rpm
Comment 4 Matthias Clasen 2006-06-14 15:39:26 EDT
err, wrong again: 

Spec URL: http://people.redhat.com/mclasen/review/imlib.spec
SRPM URL: http://people.redhat.com/mclasen/review/imlib-1.9.13-27.src.rpm
Comment 5 Kevin Fenzi 2006-06-19 16:27:42 EDT
OK - Package name
OK - Spec file matches base package name.
OK - Meets Packaging Guidelines.
OK - License (LGPL)
OK - License field in spec matches
See below - License file included in package
OK - Spec in American English
OK - Spec is legible.
OK - Sources match upstream md5sum:
8ab3f6ea596f731d54c18385bcc3525f  imlib-1.9.13.tar.gz
8ab3f6ea596f731d54c18385bcc3525f  imlib-1.9.13.tar.gz.1
See below - Package compiles and builds on at least one arch.
n/a - Package needs ExcludeArch
OK - BuildRequires correct
n/a - Spec handles locales/find_lang
OK - Spec has needed ldconfig in post and postun
n/a - Package is relocatable and has a reason to be.
OK - Package owns all the directories it creates.
OK - Package has no duplicate files in %files.
OK - Package has %defattr and permissions on files is good.
OK - Package has a correct %clean section.
OK - Spec has consistant macro usage.
OK - Package is code or permissible content.
n/a - -doc subpackage needed/used.
OK - Packages %doc files don't affect runtime.
OK - Headers/static libs in -devel subpackage.
OK - .pc files in -devel subpackage.
OK - .so files in -devel subpackage.
OK - -devel package Requires: %{name} = %{version}-%{release}
n/a - .la files are removed.
n/a - Package is a GUI app and has a .desktop file
n/a - Package doesn't own any directories other packages own.
See below - No rpmlint output.

Issues:

1. Source: URL isn't right. Perhaps it should be:
http://ftp.gnome.org/pub/GNOME/sources/imlib/1.9/imlib-%{version}.tar.gz

2. 1.9.15 is the current version, should upgrade?
Might reduce the patches as well since there is a comment about
backported fixes from 1.9.14.

3. URL: perhaps should be http://www.enlightenment.org/Libraries/Imlib.html ?

4. Should include the LGPL from COPYING.LIB

5. Building with mock for fc5, the build fails and I get:
...
 gcc -DDJPEG_PROG=\"/usr/bin/djpeg\" -DCJPEG_PROG=\"/usr/bin/cjpeg\"
-DCONVERT_PATH=\"\" -DNETPBM_PATH=\"\" -DSYSTEM_IMRC=\"/etc/imrc\"
-DIMLIB_LIB=\"/usr/lib\" -DSYSCONFDIR=\"/etc\" -I. -I. -I.. -I./..
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
-I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
-fasynchronous-unwind-tables -Wp,-MD,.deps/cache.pp -c cache.c  -fPIC -DPIC -o
.libs/cache.o
In file included from cache.c:5:
gdk_imlib_private.h:104: error: expected specifier-qualifier-list before
'XShmSegmentInfo'
make[2]: *** [cache.lo] Error 1
make[2]: Leaving directory `/builddir/build/BUILD/imlib-1.9.13/gdk_imlib'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/imlib-1.9.13'
make: *** [all-recursive-am] Error 2
error: Bad exit status from /var/tmp/rpm-tmp.58804 (%build)

It builds ok in just fc5 from the command line, so might be a missing BR or
the like under mock?

6. rpmlint output:

E: imlib invalid-soname /usr/lib/libimlib-xpm.so libimlib-xpm.so
E: imlib invalid-soname /usr/lib/libimlib-jpeg.so libimlib-jpeg.so
E: imlib invalid-soname /usr/lib/libimlib-tiff.so libimlib-tiff.so
E: imlib invalid-soname /usr/lib/libimlib-ppm.so libimlib-ppm.so
E: imlib invalid-soname /usr/lib/libimlib-bmp.so libimlib-bmp.so
E: imlib invalid-soname /usr/lib/libimlib-ps.so libimlib-ps.so
E: imlib invalid-soname /usr/lib/libimlib-gif.so libimlib-gif.so
E: imlib invalid-soname /usr/lib/libimlib-png.so libimlib-png.so

invalid-soname :
The soname of the library is neither of the form lib<libname>.so.<major> or
lib<libname>-<major>.so.
Comment 6 Paul Howarth 2006-06-28 12:05:20 EDT
Builds fine for me in mock for development-i386 with reduced buildroot.
Comment 7 Kevin Fenzi 2006-06-28 13:53:53 EDT
Yeah, I can confirm it builds fine in fc6/devel here under mock as well. 
It does not build under fc5 however (see build.log error in comment #5)
Comment 8 Paul Howarth 2006-06-28 13:59:09 EDT
(In reply to comment #7)
> Yeah, I can confirm it builds fine in fc6/devel here under mock as well. 
> It does not build under fc5 however (see build.log error in comment #5)

Does that matter? imlib is in Core for FC-5 so there will never be an FC-5
branch for it in Extras.
Comment 9 Kevin Fenzi 2006-06-28 14:02:48 EDT
(in reply to comment #8)
>Does that matter? imlib is in Core for FC-5 so there will never be an FC-5
>branch for it in Extras.

True. It's not a blocker, but I thought I would mention it. 
Comment 10 Michael J Knox 2006-06-28 18:55:20 EDT
Small updates

Spec URL: http://www.knox.net.nz/~michael/imlib.spec
SRPM URL: http://www.knox.net.nz/~michael/imlib-1.9.13-28.src.rpm

1: fixed
2: I have not looked at upgrade to the newer version. Will do soon. 
3: fixed
4: fixed
5: won't fix as this is for FC6 and beyond. 
6: Suggestions? 
Comment 11 Kevin Fenzi 2006-06-29 21:35:12 EDT
Excellent. 

ok on 1-5. 

On 6 I'm not sure. It's not good that it's a .so that doesn't have a major name 
in it, but this is very much a legacy library. 

Perhaps it's worth asking on the extras/maintainers list about it? 
It's been this way for ages and I'm afraid fixing it would break something, so 
not sure it's a blocker in this case. Perhaps someone on the list would have 
ideas on how to fix it without intrusive and difficult patches?
Comment 12 Michael J Knox 2006-06-29 21:39:35 EDT
OK, I have dropped an email to the maintainers list. Lets see what happens. 
Comment 13 David Eisenstein 2006-06-29 23:47:13 EDT
(In reply to comment #5)
> <<snip>>
> 5. Building with mock for fc5, the build fails and I get:
> ...
>  gcc -DDJPEG_PROG=\"/usr/bin/djpeg\" -DCJPEG_PROG=\"/usr/bin/cjpeg\"
> -DCONVERT_PATH=\"\" -DNETPBM_PATH=\"\" -DSYSTEM_IMRC=\"/etc/imrc\"
> -DIMLIB_LIB=\"/usr/lib\" -DSYSCONFDIR=\"/etc\" -I. -I. -I.. -I./..
> -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include
> -I/usr/include/gtk-1.2 -I/usr/include/glib-1.2 -I/usr/lib/glib/include -O2 -g
> -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
> --param=ssp-buffer-size=4 -m32 -march=i386 -mtune=generic
> -fasynchronous-unwind-tables -Wp,-MD,.deps/cache.pp -c cache.c  -fPIC -DPIC -o
> .libs/cache.o
> In file included from cache.c:5:
> gdk_imlib_private.h:104: error: expected specifier-qualifier-list before
> 'XShmSegmentInfo'
> make[2]: *** [cache.lo] Error 1
> make[2]: Leaving directory `/builddir/build/BUILD/imlib-1.9.13/gdk_imlib'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/builddir/build/BUILD/imlib-1.9.13'
> make: *** [all-recursive-am] Error 2
> error: Bad exit status from /var/tmp/rpm-tmp.58804 (%build)
> 
> It builds ok in just fc5 from the command line, so might be a missing BR or
> the like under mock?
> 
> 6. rpmlint output:
> 
> E: imlib invalid-soname /usr/lib/libimlib-xpm.so libimlib-xpm.so
> E: imlib invalid-soname /usr/lib/libimlib-jpeg.so libimlib-jpeg.so
> E: imlib invalid-soname /usr/lib/libimlib-tiff.so libimlib-tiff.so
> E: imlib invalid-soname /usr/lib/libimlib-ppm.so libimlib-ppm.so
> E: imlib invalid-soname /usr/lib/libimlib-bmp.so libimlib-bmp.so
> E: imlib invalid-soname /usr/lib/libimlib-ps.so libimlib-ps.so
> E: imlib invalid-soname /usr/lib/libimlib-gif.so libimlib-gif.so
> E: imlib invalid-soname /usr/lib/libimlib-png.so libimlib-png.so
> 
> invalid-soname :
> The soname of the library is neither of the form lib<libname>.so.<major> or
> lib<libname>-<major>.so.

There was mention in fedora-maintainers list about this being a legacy issue...
Do you mean that these packages or libraries that are causing these problems
are being maintained by the Fedora Legacy team at this time?

What versions of Fedora Core is this package being built for?

Or do you mean something else? 
Comment 14 Michael J Knox 2006-06-29 23:54:36 EDT
"There was mention in fedora-maintainers list about this being a legacy issue..."

Can you provide the url to the message? I posted today about it on maintainers@
so if its been covered, I missed it. 
Comment 15 Kevin Fenzi 2006-06-29 23:59:01 EDT
Legacy is perhaps a poor choice of words. I was meaning it in the sense that 
this is an old library that hasn't had an upstream release in a long time, and 
is only needed for older gtk1 apps that haven't been ported to gtk2. 

So, things like sonames having a valid major version in them are possibly 
things that were not common package practice at the time this package was 
released. (The 1.9.13 release was in 2002)
Comment 16 David Eisenstein 2006-06-30 00:12:42 EDT
(In reply to comment #14)
> "There was mention in fedora-maintainers list about this being a legacy issue..."
> 
> Can you provide the url to the message? I posted today about it on maintainers@
> so if its been covered, I missed it. 

Yup.  

http://www.redhat.com/archives/fedora-maintainers/2006-June/msg00179.html

I think it was your post.  Thanks.  Sorry for the noise.  -David
Comment 17 David Eisenstein 2006-06-30 00:24:58 EDT
Please don't flame me, as this is a bit off-topic.

There is, incidentally, a GTK1 app (a GUI file-manager) I am interested in
continuing to be able to run on future Fedora Cores called "Gentoo."  
<http://www.obsession.se/gentoo/>  (A different Gentoo than the Linux 
distro.)  Do you see continued Extras community interest in maintaining
GTK1 for the foreseeable future?

As a Fedora Legacy maintainer, I have thought about jumping on board Extras to
help with your efforts.  Do you all have too many wannabe Extras maintainers
already?  (That's the impression I have received from the discussions on the
FAB list.)  Thanks.  -David
Comment 18 Jason Tibbitts 2006-06-30 01:01:10 EDT
(In reply to comment #17)

> Do you all have too many wannabe Extras maintainers already?

I can state unequivocally that we can always use more package maintainers. 
(Extras contributors all maintain specific packages.)  However, we do have a
procedure for becoming a contributor which requires that you demonstrate
familiarity with our packaging procedures and guidelines, which is generally
done by assisting with reviews of new packages.  See
http://fedoraproject.org/wiki/Extras/Contributors for more information.
Comment 19 Paul Howarth 2006-06-30 03:12:19 EDT
(In reply to comment #17)
> Please don't flame me, as this is a bit off-topic.
> 
> There is, incidentally, a GTK1 app (a GUI file-manager) I am interested in
> continuing to be able to run on future Fedora Cores called "Gentoo."  
> <http://www.obsession.se/gentoo/>  (A different Gentoo than the Linux 
> distro.)

I remember using that several years ago.

> Do you see continued Extras community interest in maintaining
> GTK1 for the foreseeable future?

Yes. GTK1 has been dropped from Core and is in the process of moving to Extras,
where there will many users of it for a long while to come I expect.

> As a Fedora Legacy maintainer, I have thought about jumping on board Extras to
> help with your efforts.  Do you all have too many wannabe Extras maintainers
> already?  (That's the impression I have received from the discussions on the
> FAB list.)  Thanks.  -David

I concur with Jason; there is a limit to how many packages any one person can
sensibly maintain, so if extras is going to grow then it needs more maintainers.
Comment 20 Michael J Knox 2006-07-02 15:37:02 EDT
OK.. getting back to what the purpose of this bugzilla report is about!

To the question of if its worth fixing, was no. The email is on the maintainer's
list. 

Kevin, are you happy with the state of this package now? 
Comment 21 Kevin Fenzi 2006-07-03 12:18:06 EDT
Yeah, since the package isn't active upstream, and fixing that soname issue 
could well break all the legacy apps (or at least require changes from them), I 
agree it's ok to leave it as it is. 

That was the last blocker I saw, so this package is APPROVED. 

Don't forget to close this bug NEXTRELEASE once it's been imported and built. 
Comment 22 Michael J Knox 2006-07-03 19:16:36 EDT
Awesome! Thank you Kevin. On the buildsys now... 
Comment 23 Christian Iseli 2006-12-31 05:57:41 EST
Fixed typo...

Note You need to log in before you can comment on or make changes to this bug.