Bug 181753 - Review Request: mm - Shared memory allocation library
Review Request: mm - Shared memory allocation library
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: Package Review (Show other bugs)
rawhide
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jochen Schmitt
Fedora Package Reviews List
:
Depends On:
Blocks: FE-ACCEPT
  Show dependency treegraph
 
Reported: 2006-02-16 02:46 EST by Andreas Thienemann
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-06 04:52:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andreas Thienemann 2006-02-16 02:46:48 EST
Spec Name or Url: http://helena.bawue.de/~ixs/mm/mm.spec
SRPM Name or Url: http://helena.bawue.de/~ixs/mm/mm-1.4.0-1.src.rpm
Description:
OSSP mm is a 2-layer abstraction library which simplifies the usage of
shared memory between forked (and this way strongly related) processes
under Unix platforms. On the first layer it hides all platform dependent
implementation details (allocation and locking) when dealing with shared
memory segments and on the second layer it provides a high-level
malloc(3)-style API for a convenient and well known way to work with
data structures inside those shared memory segments.
Comment 1 Jochen Schmitt 2006-02-16 11:47:15 EST
Good:
+ md5sum of source tar file ok.
+ Local build workes fine.
* Build on mock (fedora-devel) workes fine.

Bad:
- Please use make %{?smp_mlfags} if possible.
- inconsitent use of $RPM_BUILD_ROOT and %{buildroot}
- Don't put .a file in devel package.
- /usr/lib/libmm.so.14.0.20 is not stripped.

Comment 2 Andreas Thienemann 2006-02-16 13:17:48 EST
(In reply to comment #1)

> Bad:
> - Please use make %{?smp_mlfags} if possible.
> - inconsitent use of $RPM_BUILD_ROOT and %{buildroot}
> - Don't put .a file in devel package.
> - /usr/lib/libmm.so.14.0.20 is not stripped.
fixed.
Comment 3 Jochen Schmitt 2006-02-17 05:42:34 EST
In general: Please increase the release count for eatch new relase of your 
package. You should do this even for the review process.

Comment 4 Jochen Schmitt 2006-02-19 14:29:45 EST
Question: Is it realy inpossible to use %{?_smp_mflags}?

Bad:
- mm-debuginfo contains no debug information.

BTW: Sorry for the typo in comment #1.

Comment 5 Andreas Thienemann 2006-02-19 14:37:22 EST
(In reply to comment #4)
 
> Bad:
> - mm-debuginfo contains no debug information.
Uhm. I have absolutely no clue about the debuginfo packages.
Got any hints about this problem?
Comment 6 Jochen Schmitt 2006-02-20 14:50:19 EST
Of course.

the debuginfo package contains the debugging information. This will be created,
when you compiled a program with the -g compiler switch. 

Before the RPM will be created the binaries will be stripped and the debug
informations will be stored in seperates files which going to the debuginfo package.

When you install a debuginfo package, the content of the package will be
installed on /usr/src7debug.
Comment 7 Andreas Thienemann 2006-02-20 19:28:25 EST
Yeah. But what to do in case the debuginfo package contains no debug
information? I surely didn't remove them from the package, so I can't put them
back in. ;-D
Comment 8 Ville Skyttä 2006-02-21 00:29:35 EST
Look for something that strips the binaries during build, and get rid of that. 
"strip", "install -s", and "ld -s" are common culprits.

Oh... I see you're running strip yourself in the specfile, so yes, you _did_
remove that stuff from the package.  Don't do that, just have redhat-rpm-config
installed and let rpmbuild take care of it.
Comment 9 Andreas Thienemann 2006-02-21 04:51:59 EST
Ahrgl.
Right. I put a strip call in there. Sorry, forgot about that.
Now that I think about it, I did this as otherwise rpmlint would complain about 
"W: mm unstripped-binary-or-object /usr/lib/libmm.so.14.0.20".

I thought just stripping the lib would be enough, but didn't think about the
debugpackage.
The problem were wrong permissions, which made find-debuginfo.sh not pick up the
library.

Fixed now & spec updated.
Comment 10 Jochen Schmitt 2006-02-21 11:45:48 EST
When you increase the relase count you should post a link to the new uploaded
package.

Good:
+ rpmlint to source rpm is ok.
+ rpmlint to binary rpms are ok.
+ mock build worked fine.

Bad:
- debuginfo package doesn't contains source files for debugging.

As far as I can see, you don't use the -g compiler flag. Pless see the following
part of my compile run:

./libtool --quiet --mode=compile gcc -c -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexce
ptions -m32 -march=i686 -mtune=pentium4 -fasynchronous-unwind-tables mm_global.c
./libtool --quiet --mode=compile gcc -c -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexce
ptions -m32 -march=i686 -mtune=pentium4 -fasynchronous-unwind-tables mm_alloc.c
./libtool --quiet --mode=compile gcc -c -O2 -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexce
Comment 11 Andreas Thienemann 2006-03-02 14:43:43 EST
Okay. I passed --enable-debug to the %configure macro. Otherwise libtool would
remove -g from the CFLAGS. Schtupid.

Anyway, updated package is uploaded: 
Spec Name or Url: http://helena.bawue.de/~ixs/mm/mm.spec
SRPM Name or Url: http://helena.bawue.de/~ixs/mm/mm-1.4.0-3.src.rpm
Comment 12 Jochen Schmitt 2006-03-05 14:05:36 EST
Good:
+ rpmlint of source rpm ok.
+ local build workes fine.
+ rpmlint of binaries packages ok.
+ debuginfo packages ok.
+ build fine on mock.
+ local install work fine.
+ local remove of the packages worked fine.

You package is APPROVED !!!


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