[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] > > 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. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 <[EMAIL PROTECTED]> changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #25 from Eric Munson <[EMAIL PROTECTED]> 2008-12-05 10:43:26 EDT --- Package Change Request == Package Name: libhugetlbfs New Branches: F-10 Owners: Eric Munson [EMAIL PROTECTED] I would like to be able to update Fedora 10 with the libhugetlbfs release that just went out. -- Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|CLOSED Resolution||NEXTRELEASE --- Additional Comments From [EMAIL PROTECTED] 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO|177841 | nThis|| -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO|163778 |163779 nThis|| --- Additional Comments From [EMAIL PROTECTED] 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. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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=PackagingGuidelines#head-b7d622f4bb245300199c6a33128acce5fb453213 show 0:1.0-0.fdr.2 as an example. Does that page need updating or am I misunderstanding something? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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. :) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 2006-06-24 18:24 EST --- (In reply to comment #13) > 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) 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-devellistssourceforgenet. > 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). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEEDINFO|ASSIGNED CC||[EMAIL PROTECTED] Flag|needinfo? | --- Additional Comments From [EMAIL PROTECTED] 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)? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added Flag||needinfo? --- Additional Comments From [EMAIL PROTECTED] 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... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|NEEDINFO --- Additional Comments From [EMAIL PROTECTED] 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? -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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... -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO||163778 nThis|| -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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.0 -0400 +++ libhugetlbfs-20060621/Makefile 2006-06-21 14:27:05.0 -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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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?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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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). -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 2006-06-20 15:24 EST --- I have sponsor status. Review away. I'll be watching. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|[EMAIL PROTECTED] |[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 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. -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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) -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] 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 -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review
[Bug 196057] Review Request: libhugetlbfs - easy access to huge pages of memory
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 [EMAIL PROTECTED] changed: What|Removed |Added OtherBugsDependingO|163776 |177841 nThis|| -- Configure bugmail: https://bugzilla.redhat.com/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. ___ Fedora-package-review mailing list Fedora-package-review@redhat.com http://www.redhat.com/mailman/listinfo/fedora-package-review