[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. 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 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 --- 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 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 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=showredirect=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 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
--- 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-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-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-develatlistsdotsourceforgedotnet. 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-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 [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 [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|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
--- 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 --- 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 [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 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 --- 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-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.67view=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 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 [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
[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 --- 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 [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: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
