Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory Product: Fedora Extras Version: devel Platform: All OS/Version: Linux Status: NEW Severity: normal Priority: normal Component: Package Review AssignedTo: bugzilla-sink@leemhuis.info ReportedBy: drfickle@k-lug.org QAContact: fedora-package-review@redhat.com
Spec URL: http://flooterbu.net/fedora/libhugetlbfs.spec SRPM URL: http://flooterbu.net/fedora/libhugetlbfs-20060619-1.src.rpm Description: libhugetlbfs is a library which provides easy access to huge pages of memory. It is a wrapper for the hugetlbfs file system. Applications can use huge pages to fulfill malloc() requests without being recompiled by using LD_PRELOAD. Alternatively, applications can be linked against libhugetlbfs without source modifications to load BSS or BSS, data, and text segments into large pages.
This is my first package and I am seeking a sponsor.
Note: This package is currently intended for FC5 only, due to kernel/glibc-headers changes in Rawhide. This is a temporary situation until libhugetlbfs can accomodate these changes.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
drfickle@k-lug.org changed:
What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163776 |177841 nThis| |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-20 14:32 EST ------- 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
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-20 15:02 EST ------- 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)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
jwilson@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED AssignedTo|bugzilla-sink@leemhuis.info |jwilson@redhat.com
------- Additional Comments From jwilson@redhat.com 2006-06-20 15:16 EST ------- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwboyer@jdub.homelinux.org 2006-06-20 15:24 EST ------- I have sponsor status. Review away. I'll be watching.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-21 10:20 EST ------- 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).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From drfickle@k-lug.org 2006-06-21 13:57 EST ------- 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?re...
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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-21 14:27 EST ------- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From drfickle@k-lug.org 2006-06-22 11:52 EST ------- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
tibbs@math.uh.edu changed:
What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO| |163778 nThis| |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-22 23:28 EST ------- 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...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
drfickle@k-lug.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO
------- Additional Comments From drfickle@k-lug.org 2006-06-23 10:12 EST ------- 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?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
jwilson@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flag| |needinfo?
------- Additional Comments From jwilson@redhat.com 2006-06-23 10:34 EST ------- 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...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
nacc@us.ibm.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED CC| |nacc@us.ibm.com Flag|needinfo? |
------- Additional Comments From nacc@us.ibm.com 2006-06-23 13:24 EST ------- 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)?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-23 13:30 EST ------- 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...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From nacc@us.ibm.com 2006-06-24 18:24 EST ------- (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).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-25 01:34 EST ------- Okay, two patches mailed to libhugetlbfs-devel. Out of time at the moment, will address the multiple hugetlbd part tomorrow...
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-26 10:20 EST ------- 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. :)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From drfickle@k-lug.org 2006-06-27 16:43 EST ------- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-28 00:43 EST ------- 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. :)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From drfickle@k-lug.org 2006-06-28 10:37 EST ------- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwilson@redhat.com 2006-06-28 11:24 EST ------- (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).
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From drfickle@k-lug.org 2006-06-28 12:02 EST ------- 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=... show 0:1.0-0.fdr.2 as an example. Does that page need updating or am I misunderstanding something?
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
jwilson@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|163778 |163779 nThis| |
------- Additional Comments From jwilson@redhat.com 2006-06-28 12:27 EST ------- 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. :)
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
------- Additional Comments From jwboyer@jdub.homelinux.org 2006-06-28 15:10 EST ------- (In reply to comment #22)
Package APPROVED. Josh, you're on for sponsorship. :)
Done. Everyone invovled has done a great job.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
jwboyer@jdub.homelinux.org changed:
What |Removed |Added ---------------------------------------------------------------------------- OtherBugsDependingO|177841 | nThis| |
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug report.
Summary: Review Request: libhugetlbfs - easy access to huge pages of memory
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=196057
drfickle@k-lug.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |CLOSED Resolution| |NEXTRELEASE
------- Additional Comments From drfickle@k-lug.org 2006-06-30 10:21 EST ------- 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.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=196057
Eric Munson ebmunson@us.ibm.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |ebmunson@us.ibm.com
--- Comment #25 from Eric Munson ebmunson@us.ibm.com 2008-12-05 10:43:26 EDT --- Package Change Request ====================== Package Name: libhugetlbfs New Branches: F-10 Owners: Eric Munson ebmunson@us.ibm.com
I would like to be able to update Fedora 10 with the libhugetlbfs release that just went out.
Please do not reply directly to this email. All additional comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=196057
--- Comment #26 from Josh Boyer jwboyer@gmail.com 2008-12-05 15:50:59 EDT --- (In reply to comment #25)
Package Change Request
Package Name: libhugetlbfs New Branches: F-10 Owners: Eric Munson ebmunson@us.ibm.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.
package-review@lists.fedoraproject.org