Build attempt on FC5/x86_64:

Executing(%prep): /bin/sh -e /build/tmp/rpm-tmp.16797
+ umask 022
+ cd /build/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /build/BUILD
+ rm -rf libhugetlbfs-20060619
+ /usr/bin/gzip -dc /build/sources/libhugetlbfs/libhugetlbfs-20060619.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd libhugetlbfs-20060619
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
++ /usr/bin/id -u
+ '[' 500 = 0 ']'
+ /bin/chmod -Rf a+rX,u+w,g-w,o-w .
+ exit 0
Executing(%build): /bin/sh -e /build/tmp/rpm-tmp.16797
+ umask 022
+ cd /build/BUILD
+ cd libhugetlbfs-20060619
+ LANG=C
+ export LANG
+ unset DISPLAY
+ make -j3
         CC32 obj32/hugeutils.o
         CC32 obj32/elflink.o
         CC32 obj32/morecore.o
         CC32 obj32/debug.o
elflink.c:71:2: warning: #warning __syscall_return macro not available. Some
debugging will be disabled during executable remapping
         CC64 obj64/hugeutils.o
hugeutils.c: In function 'hugetlbfs_shared_file':
hugeutils.c:369: warning: cast from pointer to integer of different size
         CC64 obj64/elflink.o
         CC64 obj64/morecore.o
         CC64 obj64/debug.o
         AR obj32/libhugetlbfs.a
         CC32 obj32/hugetlbd
ar: creating obj32/libhugetlbfs.a
a - obj32/hugeutils.o
a - obj32/elflink.o
a - obj32/morecore.o
a - obj32/debug.o
         LD32 (shared) obj32/libhugetlbfs.so
         LD64 (shared) obj64/libhugetlbfs.so
         AR obj64/libhugetlbfs.a
ar: creating obj64/libhugetlbfs.a
a - obj64/hugeutils.o
a - obj64/elflink.o
a - obj64/morecore.o
a - obj64/debug.o
         CC32 obj32/gethugepagesize.o
         CC32 obj32/testutils.o
         CC32 obj32/test_root.o
         CC32 obj32/find_path.o
         CC32 obj32/unlinked_fd.o
         CC32 obj32/readback.o
         CC32 obj32/truncate.o
         CC32 obj32/shared.o
         CC32 obj32/private.o
         CC32 obj32/empty_mounts.o
         CC32 obj32/meminfo_nohuge.o
         CC32 obj32/ptrace-write-hugepage.o
         CC32 obj32/icache-hygeine.o
         CC32 obj32/slbpacaflush.o
         CC32 obj32/chunk-overcommit.o
         CC32 obj32/mprotect.o
         CC32 obj32/alloc-instantiate-race.o
         CC32 obj32/mlock.o
         CC32 obj32/malloc.o
         CC32 obj32/malloc_manysmall.o
         CC32 obj32/dummy.o
         LD32 (preload test) obj32/zero_filesize_segment
/        CC32 obj32/linkhuge.o
         CC32 obj32/linkhuge_nofd.o
usr/bin/ld: cannot find dummy.o
collect2: ld returned 1 exit status
make[1]: *** [obj32/zero_filesize_segment] Error 1
make[1]: *** Waiting for unfinished jobs....
make: *** [tests/all] Error 2
error: Bad exit status from /build/tmp/rpm-tmp.16797 (%build)


RPM build errors:
    Bad exit status from /build/tmp/rpm-tmp.16797 (%build)

Possibly useful info on what's in the build root:
$ ll -d /build/BUILD/libhugetlbfs-20060619/tests/obj*
drwxr-xr-x 2 jwilson jwilson 4096 Jun 20 14:30
/build/BUILD/libhugetlbfs-20060619/tests/obj32

$ find /build/BUILD/libhugetlbfs-20060619/tests/ -name "dummy*"
/build/BUILD/libhugetlbfs-20060619/tests/obj32/dummy.o
/build/BUILD/libhugetlbfs-20060619/tests/dummy.d
/build/BUILD/libhugetlbfs-20060619/tests/dummy.c

I'll just go ahead and start compiling notes...

1) I'd make the version be 0.20060619, so that in the event the package switches
to a 1.x, 2.x versioning scheme, you don't have to introduce epochs to make
upgrades smooth. (You'd just have to have the first non-date-versioned package
be like 0.3 or higher).

2) You have an empty %doc line in the %files section of the base package... If
there are no docs, remove the line, if there are docs, list 'em. :)

3) In the -devel subpackage, you're including static libs. Are these necessary
for proper usage? Typically, static libs are frowned upon in Fedora packages.

4) The package is failing to build in a mock fc5/i386 chroot as well as the
build failures on fc5/x86_64 (see below). Does the package try to ascertain some
information about the system its building on from 'uname -m', by chance? I'm
assuming the objs64 stuff shouldn't be trying to build on i386.

Building target platforms: i386
Building for target i386
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.26150
+ umask 022
+ cd /builddir/build/BUILD
+ LANG=C
+ export LANG
+ unset DISPLAY
+ cd /builddir/build/BUILD
+ rm -rf libhugetlbfs-20060619
+ /bin/gzip -dc /builddir/build/SOURCES/libhugetlbfs-20060619.tar.gz
+ tar -xf -
+ STATUS=0
+ '[' 0 -ne 0 ']'
+ cd libhugetlbfs-20060619
+ exit 0
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.26150
+ umask 022
+ cd /builddir/build/BUILD
+ cd libhugetlbfs-20060619
+ LANG=C
+ export LANG
+ unset DISPLAY
+ make -j4
         CC32 obj32/hugeutils.o
         CC32 obj32/elflink.o
         CC32 obj32/morecore.o
         CC32 obj32/debug.o
hugeutils.c: In function 'hugetlbfs_shared_file':
hugeutils.c:369: warning: cast from pointer to integer of different size
elflink.c:71:2: warning: #warning __syscall_return macro not available. Some
debugging will be disabled during executable remapping
         CC64 obj64/hugeutils.o
         CC64 obj64/elflink.o
elflink.c:1: sorry, unimplemented: 64-bit mode not compiled in
hugeutils.c:1: sorry, unimplemented: 64-bit mode not compiled in
         CC64 obj64/morecore.o
morecore.c:1: sorry, unimplemented: 64-bit mode not compiled in
elflink.c:71:2: warning: #warning __syscall_return macro not available. Some
debugging will be disabled during executable remapping
hugeutils.c: In function 'hugetlbfs_shared_file':
hugeutils.c:369: warning: cast from pointer to integer of different size
make: *** [obj64/elflink.o] Error 1
make: *** Waiting for unfinished jobs....
make: *** [obj64/hugeutils.o] Error 1
make: *** [obj64/morecore.o] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.26150 (%build)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.26150 (%build)

Ah yes, I don't have sponsor status, but I can handle all the review then get
someone to do the sponsoring when the review is complete.

I have sponsor status.  Review away.  I'll be watching.

Build attempts on FC5/x86_64 work if smp_mflags are disabled, though the
resulting build fails to package:

RPM build errors:
    File not found by glob:
/build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/*.so
    File not found by glob:
/build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/ldscripts/*
    File not found by glob:
/build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/*.a
    File not found:
/build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/libhugetlbfs/tests
    File not found by glob:
/build/tmp/libhugetlbfs-20060619-1-root-jwilson/usr/lib64/libhugetlbfs/tests/*

Looks like the bits were actually installed into /usr/lib/ instead of
/usr/lib64/. The Makefile has:

ifeq ($(ARCH),x86_64)
CC32 = gcc -m32
CC64 = gcc -m64
ELF32 = elf_i386
ELF64 = elf_x86_64
LIB32 = lib32
LIB64 = lib
endif

For Fedora, that should be LIB32=lib and LIB64=lib64. After that change, less
complaints, but the LDSCRIPTDIR is still hard-coded with lib instead of picking
up lib or lib64.

You should have the diffs I emailed last night that contain my workarounds to
get a package built on FC5/x86_64, though discussion is just getting started on
how to handle the mixed 64-bit and 32-bit nature of this package on 64-bit
platforms... (see email I just sent to fedora-extras-list).

http://flooterbu.net/fedora/libhugetlbfs.spec
http://flooterbu.net/fedora/libhugetlbfs-0.20060621-1.src.rpm

I have updated the SRPM and .spec file to address all these issues.

1) I thought about this when I originally made it but the PackagingGuidelines
page didn't address it so I figured I'd see what people said.

2) Include the license also.

3) I saw the postgresql spec file packaging them so I did too :)
http://cvs.fedora.redhat.com/viewcvs/rpms/postgresql/FC-5/postgresql.spec?rev=1.67&view=auto

4) It is building cleanly in my FC5/i386 mock env. now. Hopefully with the newer
version using lib64 for x86_64 in the Makefile that platform will work too.
Please let me know how it works for you.

Okay, everything compiles on x86_64, but the package blows up. First, the
ldscripts directory isn't getting set to what the %files section expects. I'd
recommend possibly the following Makefile change:

--- libhugetlbfs-20060621.orig/Makefile 2006-06-21 11:00:26.000000000 -0400
+++ libhugetlbfs-20060621/Makefile      2006-06-21 14:27:05.000000000 -0400
@@ -20,16 +20,19 @@
 ELF64 = elf64ppc
 LIB32 = lib
 LIB64 = lib64
+BASELIB = $(LIB64)
 else
 ifeq ($(ARCH),ppc)
 CC32 = gcc
 ELF32 = elf32ppclinux
 LIB32 = lib
+BASELIB = $(LIB32)
 else
 ifeq ($(ARCH),i386)
 CC32 = gcc
 ELF32 = elf_i386
 LIB32 = lib
+BASELIB = $(LIB32)
 else
 ifeq ($(ARCH),x86_64)
 CC32 = gcc -m32
@@ -38,6 +41,7 @@
 ELF64 = elf_x86_64
 LIB32 = lib
 LIB64 = lib64
+BASELIB = $(LIB64)
 endif
 endif
 endif
@@ -52,7 +56,7 @@

 LIBDIR32 = $(DESTDIR)$(PREFIX)/$(LIB32)
 LIBDIR64 = $(DESTDIR)$(PREFIX)/$(LIB64)
-LDSCRIPTDIR = $(DESTDIR)$(PREFIX)/$(LIB32)/ldscripts
+LDSCRIPTDIR = $(DESTDIR)$(PREFIX)/$(BASELIB)/ldscripts
 BINDIR = $(DESTDIR)$(PREFIX)/bin
 DOCDIR = $(DESTDIR)$(PREFIX)/share/doc/libhugetlbfs

This change puts ldscripts where x86_64 expects them, but all the 32-bit
components are still getting built and installed where rpm isn't expecting them:

RPM build errors:
    Installed (but unpackaged) file(s) found:
   /usr/lib/libhugetlbfs.a
   /usr/lib/libhugetlbfs.so
   /usr/lib/libhugetlbfs/tests/obj32/alloc-instantiate-race
   /usr/lib/libhugetlbfs/tests/obj32/chunk-overcommit
   /usr/lib/libhugetlbfs/tests/obj32/dummy
   /usr/lib/libhugetlbfs/tests/obj32/empty_mounts
   /usr/lib/libhugetlbfs/tests/obj32/find_path
   /usr/lib/libhugetlbfs/tests/obj32/gethugepagesize
   /usr/lib/libhugetlbfs/tests/obj32/icache-hygeine
   /usr/lib/libhugetlbfs/tests/obj32/linkhuge
   /usr/lib/libhugetlbfs/tests/obj32/linkhuge_nofd
   /usr/lib/libhugetlbfs/tests/obj32/linkshare
   /usr/lib/libhugetlbfs/tests/obj32/malloc
   /usr/lib/libhugetlbfs/tests/obj32/malloc_manysmall
   /usr/lib/libhugetlbfs/tests/obj32/meminfo_nohuge
   /usr/lib/libhugetlbfs/tests/obj32/mlock
   /usr/lib/libhugetlbfs/tests/obj32/mmap-cow
   /usr/lib/libhugetlbfs/tests/obj32/mmap-gettest
   /usr/lib/libhugetlbfs/tests/obj32/mprotect
   /usr/lib/libhugetlbfs/tests/obj32/private
   /usr/lib/libhugetlbfs/tests/obj32/ptrace-write-hugepage
   /usr/lib/libhugetlbfs/tests/obj32/readback
   /usr/lib/libhugetlbfs/tests/obj32/shared
   /usr/lib/libhugetlbfs/tests/obj32/shm-fork
   /usr/lib/libhugetlbfs/tests/obj32/shm-getraw
   /usr/lib/libhugetlbfs/tests/obj32/shm-gettest
   /usr/lib/libhugetlbfs/tests/obj32/slbpacaflush
   /usr/lib/libhugetlbfs/tests/obj32/test_root
   /usr/lib/libhugetlbfs/tests/obj32/truncate
   /usr/lib/libhugetlbfs/tests/obj32/unlinked_fd
   /usr/lib/libhugetlbfs/tests/obj32/xB.linkhuge
   /usr/lib/libhugetlbfs/tests/obj32/xB.linkhuge_nofd
   /usr/lib/libhugetlbfs/tests/obj32/xB.linkshare
   /usr/lib/libhugetlbfs/tests/obj32/xBDT.linkhuge
   /usr/lib/libhugetlbfs/tests/obj32/xBDT.linkhuge_nofd
   /usr/lib/libhugetlbfs/tests/obj32/xBDT.linkshare
   /usr/lib/libhugetlbfs/tests/obj32/zero_filesize_segment
   /usr/lib/libhugetlbfs/tests/run_tests.sh

It looks like what we'd really like to do for Fedora Extras is have only the
64-bit pieces built for the x86_64 package, and the 32-bit pieces built in the
i386 package, but then make both available in the x86_64 tree, so what do you
think about another Makefile target that builds only the platform's native
binaries? We could kludge around it by using %exclude statements in the spec
file as well, but a rh-install target seems cleaner.

http://flooterbu.net/fedora/libhugetlbfs.spec
http://flooterbu.net/fedora/libhugetlbfs-0.20060622-1.src.rpm

Per our IRC discussion, LDSCRIPTDIR has been moved to
/usr/lib/libhugetlbfs/ldscripts. 

I've used %exclude for now as it's simpler than hacking the Makefile. I'll work
with Adam on changing this long term.

A few problems still...

1) The Makefile still puts the ldscripts into /usr/lib/ldscripts, so the mv on x86_64 tries to move them 
from /usr/lib64/ldscripts and fails.

2) I must have been smoking something, glibc-devel.i386 isn't a valid dependency, so the build fails 
even with the i386 glibc-devel package installed on my x86_64 box.

I've been hacking up the Makefile a bit, and I have it tweaked to only build the 64-bit parts, but there's 
an issue there too -- it looks like the 64-bit build depends on some 32-bit stuff, because the build 
fails if I don't also do the 32-bit parts, like so:

+ make -j3
         CC64 obj64/hugeutils.o
         CC64 obj64/elflink.o
         CC64 obj64/morecore.o
         CC64 obj64/debug.o
         CC64 obj64/hugetlbd.o
         AR obj64/libhugetlbfs.a
         LD64 (shared) obj64/libhugetlbfs.so
ar: creating obj64/libhugetlbfs.a
a - obj64/hugeutils.o
a - obj64/elflink.o
a - obj64/morecore.o
a - obj64/debug.o
obj64/hugetlbd.o: In function `reap_files':
/build/BUILD/libhugetlbfs-20060622/hugetlbd.c:94: undefined reference to `__hugetlbfs_verbose'
obj64/hugetlbd.o: In function `kill_daemon':
/build/BUILD/libhugetlbfs-20060622/hugetlbd.c:128: undefined reference to `__hugetlbfs_verbose'
obj64/hugetlbd.o: In function `signal_handler':
/build/BUILD/libhugetlbfs-20060622/hugetlbd.c:149: undefined reference to `__hugetlbfs_verbose'
obj64/hugetlbd.o: In function `sharing_control_loop':
/build/BUILD/libhugetlbfs-20060622/hugetlbd.c:587: undefined reference to `__hugetlbfs_verbose'
obj64/hugetlbd.o: In function `main':
/build/BUILD/libhugetlbfs-20060622/hugetlbd.c:832: undefined reference to `__hugetlbfs_verbose'
obj64/hugetlbd.o:/build/BUILD/libhugetlbfs-20060622/hugetlbd.c:840: more undefined references to 
`__hugetlbfs_verbose' follow
obj64/hugetlbd.o: In function `set_path_to_file':
/build/BUILD/libhugetlbfs-20060622/hugetlbd.c:217: undefined reference to `hugetlbfs_find_path'
collect2: ld returned 1 exit status
make: *** [obj64/hugetlbd] Error 1
make: *** Waiting for unfinished jobs....


If we can get that resolved, massaging the Makefile really isn't too hard. My current alterations would 
need a fair amount more work to get things playing nice on all arches, but I suppose another potential 
interim solution would be a Makefile patch only applied on 64-bit platforms...

http://flooterbu.net/fedora/libhugetlbfs.spec
http://flooterbu.net/fedora/libhugetlbfs-0.20060622-1.src.rpm

I've updated the .spec to always look in /usr/lib for the ldscripts dir (just to
reiterate, we were unable to find any distro that provides a /usr/lib64/ldscripts).

Regarding the separation of 32bit and 64bit files, I believe that hugetlbd is
intentionally always 32bits. I will ask Nish to confirm as he is the one who
wrote that code. If that is the case, then what additional problems does this
introduce for us?

I have a work-around for the 32-bit glibc-devel dependency, and a package that
now builds on x86_64. Still sorting through a few details and cleanups in the
spec at the moment, will post more later...

RE: hugetlbd always being 32-bit. Yes, that is intentional. The original reason
was to avoid having to always ask bug submitters which version of the daemon
were you running. But, given that a 64-bit user could install both the 64-bit
and 32-bit libhugetlbfs packages, this also happens to avoid deciding which
hugetlbd should exist, right (as both obj32/hugetlbd and obj64/hugetlbd would be
installed into the same location)?

Okay, so I've got the package building only the required binaries (no need for
%exclude), and the correct 32-bit glibc-devel dep figured out, as well as a few
minor tweaks to the spec file.

1) sub-package deps should be on %{version}-%{release}, not
%{libhugetlbfs_version}-%{release}

2) add  'BuildRequires: /usr/include/gnu/stubs-32.h' (without any %ifarch) to
make sure 32-bit glibc-devel gets pulled in (should work for ppc64 builds also)

3) you can pass LDSCRIPTDIR to make install to avoid having to move the scripts
later

4) just rm -f the .a files, using find is unnecessary

5) 32-bit ldscripts shouldn't get packaged on 64-bit builds

6) A roughly 6-line addition to the Makefile and an extra flag on the make lines
in the spec file eliminates the building of unneeded 32-bit parts on 64-bit
builds (its a little hacky, but works nicely)

Check out my diffs and resulting spec, srpm and tarball here:

http://wilsonet.com/packages/libhugetlbfs/

(I also tweaked the Makefile to put hugetlbd in sbin from the get go)

The srpm at the above URL builds quite nicely on FC5/x86_64 and in an FC5/i386
mock chroot, but is having issues in a mock FC5/x86_64 chroot, I believe due to
the default exclude flags (that mask out i386 packages)... Unfortunately, I
think they are the same on the extras build servers, so we're sort of stuck
again... :(

(Pinging folks about the build servers now to confirm)

Ack, I'm seeing another potential issue w/the current packaging breakdown, in
that as it stands right now, 32-bit and 64-bit libhugetlbfs packages would
conflict with one another, as both contain hugetlbd. I know they're actually the
same file, but we'll need to work around that somehow -- possibly yet another
sub-package...

(In reply to comment #13)

<snip>

> Check out my diffs and resulting spec, srpm and tarball here:
> 
> http://wilsonet.com/packages/libhugetlbfs/
> 
> (I also tweaked the Makefile to put hugetlbd in sbin from the get go)

<snip>

These generally look sane (in particular because they seem to work :), but we'll
probably need -p1 applicable patches and an attribution line (Signed-off-by),
ideally sent to libhugetlbfs-devel<at>lists<dot>sourceforge<dot>net.

> Ack, I'm seeing another potential issue w/the current packaging breakdown, in
> that as it stands right now, 32-bit and 64-bit libhugetlbfs packages would
> conflict with one another, as both contain hugetlbd. I know they're actually
> the same file, but we'll need to work around that somehow -- possibly yet
> another sub-package...

I posted on that exact issue a few minutes before you. Even if we had a separate
64-bit hugetlbd, it wouldn't make any difference, right? Because both would be
installed in /usr/sbin, or wherever? I don't know of any distros that
differentiate between 32-bit and 64-bit executables via the path, at least (in
contrast to libraries, for instance).

Okay, two patches mailed to libhugetlbfs-devel. Out of time at the moment, will address the multiple 
hugetlbd part tomorrow...

Okay, the hugetlbd issue...

What normally happens with packages in Fedora when we want both some 32-bit and
64-bit components available on a 64-bit system, is that the package is broken up
in such a way that there is no overlap in packages we want to have both variants
of. Whenever possible, we only put the 64-bit variants in bin and sbin, and the
32-bit pieces are generally only the libraries and headers. So what I'd suggest
in this case is splitting hugetlbd and ld.hugetlbfs off into another
sub-packages so the libhugetlbfs and libhugetlbfs-devel 32-bit packages can be
cleanly installed concurrently with the 64-bit ones.

Whether hugetlbd actually gets built 32-bit or 64-bit doesn't actually matter to
the packaging discussion above (it'll still go in an x86_64.rpm on the 64-bit
build). However, the general preference is that if it can be built 64-bit, build
it 64-bit, and that's the version that'll get installed on 64-bit systems.

So long story short, lets throw hugetlbd and ld.hugetlbfs into a -utils or -apps
sub-package, and move on from there. :)

http://flooterbu.net/fedora/libhugetlbfs.spec
http://flooterbu.net/fedora/libhugetlbfs-0.20060627-1.src.rpm

Per our discussion on IRC, we are able to keep it down to two packages as RPM
will prefer the native binaries over others when files overlap. Also, objects
are created only for the native bit-ness of the machine. 

I think all issues have been addressed now.

Full review of requirements checklist:
* package meets naming and packaging guidelines
* specfile is properly named, is cleanly written and uses macros consistently
* dist tag is present
* build root is correct -- almost, but not quite, should be %{version} in there instead of %
{libhugetlbfs_version}
* license field matches the actual license -- LGPL
* license is open source-compatible and license file is included in the package
* source files match upstream -- 
      0a34f3327babcd091f8a06c97fd99873  libhugetlbfs-20060627.tar.gz
* latest version is being packaged
* BuildRequires are proper -- need to remove /usr/include/gnu/stubs-32.h
* package builds in mock (builds for fc5/x86_64, i386 and ppc)
* rpmlint is silent -- not quite:
    W: libhugetlbfs no-soname /usr/lib64/libhugetlbfs.so
    E: libhugetlbfs script-without-shellbang /usr/share/libhugetlbfs/ldscripts/elf_x86_64.xB
    E: libhugetlbfs script-without-shellbang /usr/share/libhugetlbfs/ldscripts/elf_x86_64.xBDT

The first isn't a problem, the 2nd and 3rd we can get rid of by chmod -x'ing the ldscripts. (I'm 
assuming they don't need to be executable).

 final provides and requires are sane:
    /build/RPMS/x86_64/libhugetlbfs-0.20060627-1.x86_64.rpm
    libhugetlbfs.so()(64bit)  
    libhugetlbfs = 0.20060627-1
    =
    
    /build/RPMS/x86_64/libhugetlbfs-test-0.20060627-1.x86_64.rpm
    libhugetlbfs-test = 0.20060627-1
    =
    libhugetlbfs = 0.20060627-1
    libhugetlbfs.so()(64bit)  

* no versioned libs, okay to put .so in base package instead of -devel
* package is not relocatable.
* owns the directories it creates -- missing a '%dir %{_datadir}/libhugetlbfs' for the base package
* doesn't own any directories it shouldn't.
* no duplicates in %files.
* file permissions are appropriate.
* %clean is present.
* no %check is present, n/a
* no scriptlets present.
* code, not content.
* documentation is small, so no -docs subpackage is necessary.
* %docs are not necessary for the proper functioning of the package.
* no headers
* no pkgconfig files
* no libtool .la files
* not a GUI app
* not a web app

Just a few minor things left to iron out, we're in the home stretch. :)

http://flooterbu.net/fedora/libhugetlbfs.spec
http://flooterbu.net/fedora/libhugetlbfs-0.20060627-1.src.rpm

buildroot and buildrequires fixed. I've patched the Makefile to install those
linker scripts 644. The %dir has been added.

(In reply to comment #18)
> Full review of requirements checklist:
> * build root is correct -- almost, but not quite, should be %{version} in
there instead of %
> {libhugetlbfs_version}

Good to go.

> * BuildRequires are proper -- need to remove /usr/include/gnu/stubs-32.h

Good to go.

> * rpmlint is silent -- not quite:
>     W: libhugetlbfs no-soname /usr/lib64/libhugetlbfs.so
>     E: libhugetlbfs script-without-shellbang
/usr/share/libhugetlbfs/ldscripts/elf_x86_64.xB
>     E: libhugetlbfs script-without-shellbang
/usr/share/libhugetlbfs/ldscripts/elf_x86_64.xBDT
> 
> The first isn't a problem, the 2nd and 3rd we can get rid of by chmod -x'ing
the ldscripts. (I'm 
> assuming they don't need to be executable).

Okay, those are taken care of, but I screwed up and forgot to mention one other
than I'd manually adjusted in a local copy of the spec. The version in the
changelog should be 0.20060627-1 instead of 0:20060627-1 (rpmlint complains
about a bad revision or some such thing).

> * owns the directories it creates -- missing a '%dir %{_datadir}/libhugetlbfs'
for the base package

Good to go.

Once the version in the changelog is corrected, I believe the package is ready
for Extrafication (pending sponsorship, of course).

http://flooterbu.net/fedora/libhugetlbfs.spec
http://flooterbu.net/fedora/libhugetlbfs-0.20060628-1.src.rpm

Updated to the 20060628 release which included my Makefile patch. 

I've fixed up the changelog version, but I'm confused since the guidelines at
http://fedoraproject.org/wiki/Packaging/Guidelines?action=show&redirect=PackagingGuidelines#head-b7d622f4bb245300199c6a33128acce5fb453213
show 0:1.0-0.fdr.2 as an example. Does that page need updating or am I
misunderstanding something?

Ah, the translation of that changelog example to this package would actually be 
"0:0.20060628-1". The leading 0: isn't necessary though, as this package has no 
epoch. (Epochs are a messy and somewhat sensitive issue for some people...)

* Updated tarball md5sum matches upstream:
619c633157d45a21075e097856ad1bf6  libhugetlbfs-20060628.tar.gz

* rpmlint is now silent, save the W: about the .so that we can ignore here

Package APPROVED. Josh, you're on for sponsorship. :)

(In reply to comment #22)
> 
> Package APPROVED. Josh, you're on for sponsorship. :)

Done.  Everyone invovled has done a great job.

I saw this morning that the package is now available in Extras. Thanks much to
both Jarod and Josh for the roles you played. Though the whole process took
longer than I anticipated, Jarod performed a quality review and was very
responsive to my help requests; and that is greatly appreciated.

Package Change Request
======================
Package Name: libhugetlbfs
New Branches: F-10
Owners: Eric Munson ebmunson.com

I would like to be able to update Fedora 10 with the libhugetlbfs release that just went out.

(In reply to comment #25)
> Package Change Request
> ======================
> Package Name: libhugetlbfs
> New Branches: F-10
> Owners: Eric Munson ebmunson.com
> 
> I would like to be able to update Fedora 10 with the libhugetlbfs release that
> just went out.

So update it.  There is already an F-10 branch.