Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at
Bug 181753 - Review Request: mm - Shared memory allocation library
Summary: Review Request: mm - Shared memory allocation library
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jochen Schmitt
QA Contact: Fedora Package Reviews List
Depends On:
TreeView+ depends on / blocked
Reported: 2006-02-16 07:46 UTC by Andreas Thienemann
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2006-03-06 09:52:06 UTC
Type: ---

Attachments (Terms of Use)

Description Andreas Thienemann 2006-02-16 07:46:48 UTC
Spec Name or Url:
SRPM Name or Url:
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 16:47:15 UTC
+ md5sum of source tar file ok.
+ Local build workes fine.
* Build on mock (fedora-devel) workes fine.

- 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/ is not stripped.

Comment 2 Andreas Thienemann 2006-02-16 18:17:48 UTC
(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/ is not stripped.

Comment 3 Jochen Schmitt 2006-02-17 10:42:34 UTC
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 19:29:45 UTC
Question: Is it realy inpossible to use %{?_smp_mflags}?

- mm-debuginfo contains no debug information.

BTW: Sorry for the typo in comment #1.

Comment 5 Andreas Thienemann 2006-02-19 19:37:22 UTC
(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 19:50:19 UTC
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-21 00:28:25 UTC
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 05:29:35 UTC
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 09:51:59 UTC
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/".

I thought just stripping the lib would be enough, but didn't think about the
The problem were wrong permissions, which made not pick up the

Fixed now & spec updated.

Comment 10 Jochen Schmitt 2006-02-21 16:45:48 UTC
When you increase the relase count you should post a link to the new uploaded

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

- 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 19:43:43 UTC
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:
SRPM Name or Url:

Comment 12 Jochen Schmitt 2006-03-05 19:05:36 UTC
+ 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.