Bug 194355
Summary: | Review Request: imlib | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Matthias Clasen <mclasen> |
Component: | Package Review | Assignee: | Kevin Fenzi <kevin> |
Status: | CLOSED NEXTRELEASE | QA Contact: | Fedora Package Reviews List <fedora-package-review> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | rawhide | CC: | deisenst, michael |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-07-03 23:16:36 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | |||
Bug Blocks: | 163779 |
Description
Matthias Clasen
2006-06-07 14:30:30 UTC
As stated on fedora-extras, I will claim this package for extras. Hey Matthias, the urls do not open :-/ can you recheck them? 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 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 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. Builds fine for me in mock for development-i386 with reduced buildroot. 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) (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. (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. 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? 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? OK, I have dropped an email to the maintainers list. Lets see what happens. (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? "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. 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) (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 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 (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. (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. 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? 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. Awesome! Thank you Kevin. On the buildsys now... Fixed typo... |