Bug 461757

I will review this but first need to know what is difference between this
libdwarf and the one I found on my F9 machine libdwarves1?

(In reply to comment #1)
> I will review this but first need to know what is difference between this
> libdwarf and the one I found on my F9 machine libdwarves1?

Thanks!  Good question, there are a number of DWARF utilities and libraries here.  The dwarves and libdwarves1 packages, and elfutils's eu-readelf packages use elfutils's libdw as a dwarf reader.  Similarly, binutils includes the readelf utility.

However, the ABI's and interfaces for each are very different.  In addition, libdwarf includes a producer and DWARF verification tool (dwarfdump).

Suggestions:-
1) you can altenatively use version as
%define upstreamid 20080818
Version: 0.%{upstreamid}
This will help you in future if you switch to releases like 1.0 or 1.0.0 otherwise you need to use always date as version.

2) You should use shared libraries scriptlet as per given here https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Shared_libraries

3) you should use "install -Dp" as per given here http://fedoraproject.org/wiki/PackagingGuidelines#Timestamps

4) Though not mandatory but good if you use defattr as
%defattr(-,root,root,-)
https://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo#.25files_section

5) Package build is failed http://koji.fedoraproject.org/koji/taskinfo?taskID=819456
   You should use make as
   make %{?_smp_mflags}  CFLAGS="$RPM_OPT_FLAGS -I."


Why you want to include -static package? See http://fedoraproject.org/wiki/PackagingGuidelines#Packaging_Static_Libraries

I see no versioned libdwarf.so.*.*.* symlinks to libdwarf.so are created and not included in libdwarf rpm. Do you want to create them?
In that case then you need to follow
- MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1), then library files that end in .so (without suffix) must go in a -devel package.

(In reply to comment #3)
> Suggestions:-
> 1) you can altenatively use version as
> %define upstreamid 20080818
> Version: 0.%{upstreamid}
> This will help you in future if you switch to releases like 1.0 or 1.0.0
> otherwise you need to use always date as version.

ah, i was wondering about that; I've changed it.

> 2) You should use shared libraries scriptlet as per given here
> https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Shared_libraries

doh, missed the %postun; added

> 3) you should use "install -Dp" as per given here
> http://fedoraproject.org/wiki/PackagingGuidelines#Timestamps

I've added the -p

> 4) Though not mandatory but good if you use defattr as
> %defattr(-,root,root,-)
> https://fedoraproject.org/wiki/PackageMaintainers/CreatingPackageHowTo#.25files_section

I've changed this.

> 5) Package build is failed
> http://koji.fedoraproject.org/koji/taskinfo?taskID=819456
>    You should use make as
>    make %{?_smp_mflags}  CFLAGS="$RPM_OPT_FLAGS -I."

I've added the flags; I'm also going to check an x86-64 build (I needed to finish reviving my fedora access).

> Why you want to include -static package? See
> http://fedoraproject.org/wiki/PackagingGuidelines#Packaging_Static_Libraries

I've removed it.

It was in case a developer needed it (I think we should start making available profiled libraries also but that is another story :-).

(In reply to comment #4)
> I see no versioned libdwarf.so.*.*.* symlinks to libdwarf.so are created and
> not included in libdwarf rpm. Do you want to create them?
> In that case then you need to follow
> - MUST: If a package contains library files with a suffix (e.g. libfoo.so.1.1),
> then library files that end in .so (without suffix) must go in a -devel
> package.

For the moment no.

But where is updated SRPM and SPEC links?
whenever SPEC file get changed in review then submitter should bump release and submit new SRPM and SPEC links in package review process.

(In reply to comment #6)
> But where is updated SRPM and SPEC links?
> whenever SPEC file get changed in review then submitter should bump release and
> submit new SRPM and SPEC links in package review process.

I've just uploaded a further update to people.redhat.com/cagney/libdwarf/
Spec URL: http://people.redhat.com/cagney/libdwarf/libdwarf.spec
Srpm URL: http://people.redhat.com/cagney/libdwarf/libdwarf-0.20080818-2.fc9.src.rpm

This addresses the x86-64 build problem I mentioned (I still need to revive my koji building ability).

I see tarball SOURCE should be changed to 
http://reality.sgiweb.org/davea/%{name}-%{upstreamid}.tar.gz

other suggestion in .SPEC are as
rpmlint output on rpms are as
libdwarf.src:100: W: macro-in-%changelog upstreamid
libdwarf.src:101: W: macro-in-%changelog defattr
libdwarf.src:102: W: macro-in-%changelog postun
==> Always use %% instead single % in Changelog to avoid this rpmlint message.

libdwarf.i386: W: no-documentation
==> you must include doc files to libdwarf package as
%doc COPYING LGPL.txt README ChangeLog 

libdwarf.i386: W: no-soname /usr/lib/libdwarf.so
==> I think this mean no versioned symlinks. I still dunno how to handle this.

libdwarf.i386: W: one-line-command-in-%post /sbin/ldconfig
libdwarf.i386: W: one-line-command-in-%postun /sbin/ldconfig
==> you can use ldconfig as per given here https://fedoraproject.org/wiki/Packaging/ScriptletSnippets#Shared_libraries
%post -p /sbin/ldconfig
%postun -p /sbin/ldconfig

libdwarf-devel.i386: W: spurious-executable-perm /usr/include/libdwarf.h
==> chmod to 644 in install command as
install -m 0644 -Dp libdwarf.h $RPM_BUILD_ROOT%{_includedir}/libdwarf.h

libdwarf-devel.i386: W: summary-ended-with-dot Headers for libdwarf.
==> Remove dot at end of line and use summary as
Summary:        Development files for %{name}


libdwarf-dwarfdump.i386: W: spurious-executable-perm /usr/share/man/man1/dwarfdump.1.gz
==> chmod to 644 in install command as
install -m 0644 -Dp dwarfdump.1 $RPM_BUILD_ROOT%{_mandir}/man1/dwarfdump.1

libdwarf-dwarfdump.i386: E: only-non-binary-in-usr-lib
libdwarf-dwarfdump.i386: E: script-without-shebang /usr/lib/dwarfdump.conf
==> Configuration files should be installed in %{_sysconfdir}/

libdwarf-dwarfdump.i386: W: summary-ended-with-dot DWARF dumping utility.
==> Remove dot at end of line.


* You should add following to -devel
Requires:       %{name} = %{version}-%{release}
==> MUST: In the vast majority of cases, devel packages must require the base package using a fully versioned dependency: Requires: %{name} = %{version}-%{release} 

* You should add following to -devel
%description    devel
The %{name}-devel package contains header files for
developing applications that use %{name}.

* package dwarfdump should require main package as
Requires:       %{name} = %{version}-%{release}

Created attachment 317030 [details]
modified SPEC file to solve rpmlint messages

Here is modified SPEC file for you to simplify your work. But still rpmlint gives message with this new release as
libdwarf.i386: W: no-soname /usr/lib/libdwarf.so

Thanks for the updated file!

(In reply to comment #10)
> Created an attachment (id=317030) [details]
> modified SPEC file to solve rpmlint messages
> 
> Here is modified SPEC file for you to simplify your work. But still rpmlint
> gives message with this new release as
> libdwarf.i386: W: no-soname /usr/lib/libdwarf.so

Looking around I found a rule from another code base that uses:

.a.so:
        soname=`basename $@` ; \
        $(CC) -shared -o $@.tmp \
                -Wl,--whole-archive,$<,--no-whole-archive \
                -Wl,--soname,$$soname,-z,-defs
        if readelf -d $@.tmp | fgrep -q TEXTREL; then exit 1; fi
        mv $@.tmp $@

to build the .so; note the --soname option passed to LD (via gcc's -Wl).  I'm guessing I need to tweak things specify that; I'll check that out.

If its needed I'll also give the shared library a version number; might as well fix that as well.

Thanks for your comment.
I will be waiting for your updated SRPM package for review.

I think I'm getting close:

$ rpmlint libdwarf.spec libdwarf-0.20080818-4.fc9.src.rpm
x86_64/libdwarf-0.20080818-4.fc9.x86_64.rpm
x86_64/libdwarf-devel-0.20080818-4.fc9.x86_64.rpm
x86_64/libdwarf-debuginfo-0.20080818-4.fc9.x86_64.rpm
x86_64/libdwarf-dwarfdump-0.20080818-4.fc9.x86_64.rpm 
5 packages and 1 specfiles checked; 0 errors, 0 warnings.

Per the changelog it:
  - creates a soname branded libdwarf.so.0 / libdwarf.so
  - it installs/soft-links same

Spec URL: http://people.redhat.com/cagney/libdwarf/libdwarf.spec
Srpm URL:
http://people.redhat.com/cagney/libdwarf/libdwarf-0.20080818-4.fc9.src.rpm

Review:
+ package builds in mock (rawhide i386).
koji build => http://koji.fedoraproject.org/koji/taskinfo?taskID=841274
+ rpmlint is silent for SRPM and for RPM.
+ source files match upstream url
180e1264b77070b4814882671c4e57ba  libdwarf-20080818.tar.gz
+ package meets naming and packaging guidelines.
+ specfile is properly named, is cleanly written
+ Spec file is written in American English.
+ Spec file is legible.
+ dist tag is present.
+ build root is correct.
+ license is open source-compatible.
+ License text is included in package.
+ BuildRequires are proper.
+ Compiler flags used correctly.
+ defattr usage is correct.
+ %clean is present.
+ package installed properly.
+ Macro use appears rather consistent.
+ Package contains code, not content.
+ no static libraries.
+ no .pc file present.
+ -devel subpackage exists.
+ no .la files.
+ no translations are available.
+ Does owns the directories it creates.
+ ldconfig scriptlets present.
+ no duplicates in %files.
+ file permissions are appropriate.
+ Package libdwarf-0.20080818-4.fc10 =>
  Provides: libdwarf.so.0
  Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1.3)  libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) rtld(GNU_HASH)
+ Package libdwarf-devel-0.20080818-4.fc10 =>
   Requires: libdwarf.so.0
+ Package libdwarf-dwarfdump-0.20080818-4.fc10 =>
  Provides: config(libdwarf-dwarfdump) = 0.20080818-4.fc10
  Requires: libc.so.6 libc.so.6(GLIBC_2.0) libc.so.6(GLIBC_2.1) libc.so.6(GLIBC_2.3) libc.so.6(GLIBC_2.3.4) libc.so.6(GLIBC_2.4) libdwarf.so.0 libelf.so.1 libelf.so.1(ELFUTILS_1.0) rtld(GNU_HASH)

Suggestions:-
  Good to see soname patch also applied in upstream.
APPROVED.

Can you request for CVS and build this package and Close this review?

(In reply to comment #15)
> Can you request for CVS and build this package and Close this review?

Ok (I've now got my CVS working).

Can you request for CVS and build this package and Close this review?

Closing this now as submitter is not responding.

Created attachment 335402 [details]
generate a valid soname

Cagney,
  any plans to reopen this review and maintain this package in fedora?