Bug 191722

Summary: diskdumputils fails to build in mock
Product: [Fedora] Fedora Reporter: n0dalus <n0dalus+redhat>
Component: diskdumputilsAssignee: Linda Wang <lwang>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: rawhideCC: aimamura, anderson, dwmw2, ktokunag, ntachino
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-05-19 18:38:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 191529    
Attachments:
Description Flags
Build log
none
patch
none
diskdumputils-751312-i386-hs20-bc1-1.build.redhat.com.log
none
diskdumputils-751312-ia64-bullwinkle.build.redhat.com.log
none
diskdumputils-751312-ppc-js20-bc1-11.build.redhat.com.log
none
diskdumputils-751312-ppc64-js20-bc1-10.build.redhat.com.log
none
diskdumputils-751312-x86_64-hs20-bc1-2.build.redhat.com.log
none
diskdumputils-751312-i386-hs20-bc1-1.build.redhat.com.log
none
diskdumputils-751312-ia64-bullwinkle.build.redhat.com.log
none
diskdumputils-751312-ppc-js20-bc1-11.build.redhat.com.log
none
diskdumputils-751312-ppc64-js20-bc1-10.build.redhat.com.log
none
diskdumputils-751312-x86_64-hs20-bc1-2.build.redhat.com.log none

Description n0dalus 2006-05-15 14:18:19 UTC
Description of problem:
diskdumputils fails to build in mock.

Version-Release number of selected component (if applicable):
diskdumputils-1.2.8-4.src.rpm

Build fails with error:
diskdump_format.c:36:24: error: linux/swap.h: No such file or directory
diskdump_format.c: In function 'device_is_swap':
diskdump_format.c:513: error: dereferencing pointer to incomplete type
diskdump_format.c:515: error: dereferencing pointer to incomplete type

Comment 1 n0dalus 2006-05-15 14:18:20 UTC
Created attachment 129063 [details]
Build log

Comment 2 Dave Anderson 2006-05-17 18:55:11 UTC
Error from the build log:

  cc -g -O -Wall `pkg-config --cflags glib-2.0` -Wall -D_FILE_OFFSET_BITS=64
  -c -o diskdump_format.o diskdump_format.c
  diskdump_format.c:36:24: error: linux/swap.h: No such file or directory
  diskdump_format.c: In function 'device_is_swap':
  diskdump_format.c:513: error: dereferencing pointer to incomplete type
  diskdump_format.c:515: error: dereferencing pointer to incomplete type
  make: *** [diskdump_format.o] Error 1

/usr/include/linux/swap.h used to be part of the glibc-kernheaders package,
so I thought that it would only take a "BuildRequires: glibc-kernheaders"
to the diskdumputils.spec file to address the build problem.  However, after
trying that in the devel tree, the same error occurs.

Upon further inspection, it looks like swap.h no longer is part of the
latest glibc-kernheaders-3.0-32 package, whereas it used to be as recently
as version 3.0-2.  Perhaps it got dropped here:

  * Wed Apr 26 2006 David Woodhouse <dwmw2> 3.0-8
  - Updated tarball from 'make headers_install' from 2.6.16-1.2166_FC6
    This should match the contents of the 'kernel-headers' subpackage
    of the kernel, if I was brave enough to actually switch over to that
    for real. Let's just test it this way for now though...

Anyway, I was just trying to be helpful, but at this point I have no idea
what package contains swap.h.  





Comment 3 Dave Anderson 2006-05-17 19:23:28 UTC
Note: I do understand that swap.h can be found in the kernel-devel package,
but how would a user-package reference it?  

For example, the latest FC6 x86_64 kernel-devel-2.6.16-1.2204_FC6.x86_64.rpm
package contains swap.h here:

 ./usr/src/kernels/2.6.16-1.2204_FC6-x86_64/include/linux/swap.h

but how could a user package express the #include line? 


Comment 4 David Woodhouse 2006-05-17 21:28:00 UTC
(In reply to comment #3)
> Note: I do understand that swap.h can be found in the kernel-devel package,
> but how would a user-package reference it?  

You don't. It's a _KERNEL_ header. Finding it in the kernel-devel package should
be a big shouty warning to you that it's _NOT_ for you to use in userspace.

In particular, swap.h contains structure with a dependency on PAGE_SIZE, which
isn't even a constant -- it's system-dependent and has to be obtained with
sysconf(3).

I've committed a fix for this; diskdumputils-1.3.6-kernheaders.patch -- please
review it and build a package. I also had to do diskdumputils-1.3.6-ppc.patch so
that it would build on my test box; please review that too.

I've also fixed the BuildRequires for glibc-kernheaders. That package name
should never be used -- it provides kernel-headers, and is likely to disappear
in favour of that package again some time soon.


Comment 5 Dave Anderson 2006-05-18 13:07:48 UTC
> I've committed a fix for this; diskdumputils-1.3.6-kernheaders.patch -- please
> review it and build a package. I also had to do diskdumputils-1.3.6-ppc.patch
> so that it would build on my test box; please review that too.

Thanks Dave!  I wasn't really trolling for a fix, but just trying
to get an idea for what the Fujitsu team could do with their package
if/when Brew is ever used for RHEL3 and RHEL4.  Even though the Fujitsu
guys are embedded in Westford, they cannot access CVS, do errata, etc.,
so I'm just a "proxy" maintainer.

To the Fujitsu team:

If you missed this, the QA group is validating all Fedora packages for
proper BuildRequires usage in package spec files:

http://post-office.corp.redhat.com/archives/os-devel-list/2006-May/msg00105.html

Even though diskdumputils is not supported in Fedora, if the Beehive build
system is replaced by Brew for future builds of RHEL3 and RHEL4, the
build issue would have to be addressed.

Can you guys verify the two patch files made by Dave Woodhouse, and fold them
into future upstream packages?

The two patches can be found in:

 porkchop:/home/boston/anderson/diskdumputils/devel

And thanks again, Dave.


Comment 6 David Woodhouse 2006-05-18 13:32:59 UTC
Actually, this error wasn't really anything to do with the BuildRequires: effort
-- it was just coincidence that this was the first time the diskdumputils
package was built after the kernel-headers package got changed.

The real problem is that <linux/swap.h> just isn't suitable for use in userspace
now that PAGE_SIZE really is variable -- which is why I've done that part
differently.

The patch to support PPC32 was partly just so that I could get to the real
problem on my laptop -- and partly because I object to the existence of _any_
package which doesn't build for PPC32. If we do start building for ppc32 in
Fedora (and I think we should), then we may need some special installer magic to
make sure the PPC64 version gets included for PPC64 machines -- like we do for
gdb and the kernel. We don't want to end up installing the ppc32 version on
64-bit machines.

Comment 7 Dave Anderson 2006-05-18 14:35:38 UTC
Hi Dave,

The ppc package won't build:

...
echo "#define CMD_VERSION \"1.3.6\"" > version.h
cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64   -c -o diskdumpctl_proc.o
diskdumpctl_proc.c
cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64   -c -o diskdumpcmn.o diskdumpcmn.c
cc -o diskdumpctl_proc diskdumpctl_proc.o diskdumpcmn.o
cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64   -c -o savecore.o savecore.c
savecore.c: In function 'main':
savecore.c:539: warning: 'data[1]' may be used uninitialized in this function
cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64   -c -o elf.o elf.c
cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64   -c -o ppc/elf.o ppc/elf.c
cc -g -O -Wall -Wall -D_FILE_OFFSET_BITS=64   -c -o dumpfile.o dumpfile.c
if [ -d /usr/lib64 ]; \
then cc -o savecore savecore.o dumpfile.o elf.o ppc/elf.o diskdumpcmn.o
/usr/lib64/libz.a ; \
else cc -o savecore savecore.o dumpfile.o elf.o ppc/elf.o diskdumpcmn.o
/usr/lib/libz.a ; fi
cc: /usr/lib64/libz.a: No such file or directory
make: *** [savecore] Error 1
error: Bad exit status from /usr/src/build/751299-ppc/install-tmp/rpm-tmp.91285
(%build)


Comment 8 David Woodhouse 2006-05-18 14:50:12 UTC
Checking for the existence of /usr/lib64 isn't the best way to decide whether to
use it. Why shouldn't we be allowed to build for 32-bit on a 64-bit machine.

Use %{_libdir} in the RPM specfile instead. We should also be using
$RPM_OPT_FLAGS. I'll attach a patch which starts this but still needs LDFLAGS to
be set -- sorry, got to run.

Comment 9 David Woodhouse 2006-05-18 14:51:49 UTC
Created attachment 129430 [details]
patch

Comment 10 Dave Anderson 2006-05-18 15:38:49 UTC
With added diskdumputils-1.3.6-libdir.patch and modified diskdumputils.spec file
the build worked -- logs to be attached...

Comment 11 Dave Anderson 2006-05-18 15:40:13 UTC
Created attachment 129437 [details]
diskdumputils-751312-i386-hs20-bc1-1.build.redhat.com.log

Comment 12 Dave Anderson 2006-05-18 15:41:17 UTC
Created attachment 129439 [details]
diskdumputils-751312-ia64-bullwinkle.build.redhat.com.log

Comment 13 Dave Anderson 2006-05-18 15:42:27 UTC
Created attachment 129441 [details]
diskdumputils-751312-ppc-js20-bc1-11.build.redhat.com.log

Comment 14 Dave Anderson 2006-05-18 15:43:22 UTC
Created attachment 129442 [details]
diskdumputils-751312-ppc64-js20-bc1-10.build.redhat.com.log

Comment 15 Dave Anderson 2006-05-18 15:44:20 UTC
Created attachment 129443 [details]
diskdumputils-751312-x86_64-hs20-bc1-2.build.redhat.com.log

Comment 16 Dave Anderson 2006-05-18 15:49:13 UTC
Created attachment 129447 [details]
diskdumputils-751312-i386-hs20-bc1-1.build.redhat.com.log

Comment 17 Dave Anderson 2006-05-18 15:50:59 UTC
Created attachment 129448 [details]
diskdumputils-751312-ia64-bullwinkle.build.redhat.com.log

Comment 18 Dave Anderson 2006-05-18 15:52:18 UTC
Created attachment 129449 [details]
diskdumputils-751312-ppc-js20-bc1-11.build.redhat.com.log

Comment 19 Dave Anderson 2006-05-18 15:53:57 UTC
Created attachment 129450 [details]
diskdumputils-751312-ppc64-js20-bc1-10.build.redhat.com.log

Comment 20 Dave Anderson 2006-05-18 15:55:18 UTC
Created attachment 129451 [details]
diskdumputils-751312-x86_64-hs20-bc1-2.build.redhat.com.log

Comment 21 Dave Anderson 2006-05-18 15:57:56 UTC
> the build worked -- logs to be attached...

Sorry about that -- I thought "auto-detect" would figure out that the logs
were plain text.


Comment 22 David Woodhouse 2006-05-19 19:21:44 UTC
Don't forget the build system magic. You don't want to ship ppc32 diskdumputils
on ppc64 machines.

Comment 23 Dave Anderson 2006-05-19 19:28:26 UTC
This package is not even supported in Fedora.

The only reason I got involved is just in case the same
type of build issues were ever to raise their heads in
a future RHEL3 or RHEL4 errata, i.e., if Brew replaces
Beehive there.  (I'm presuming that's going to happen?)
Anyway, in RHEL3 and RHEL4, ppc will *never* make it into
the ExclusiveArch lineup.


Comment 24 David Woodhouse 2006-05-19 19:41:35 UTC
That's assuming you deliberately change it and rebuild for RHEL5, instead of the
Fedora packages just getting inherited into the RHEL5 tree.

Better to fix it properly and never worry about it again -- and better for it to
_work_ in Fedora too.

Comment 25 Dave Anderson 2006-05-19 19:44:51 UTC
Diskdump (and netdump) are being phased out in RHEL5,
to be replaced by kexec/kdump.



Comment 26 Dave Anderson 2006-05-19 20:07:05 UTC
Also, there has never been *kernel* diskdump support the ppc platform,
so a ppc32 diskdumputils package has nobody to talk to.