Bug 89835
Summary: | dump output file is larger than expected | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Christopher R. Wren <redhat> |
Component: | dump | Assignee: | Mike A. Harris <mharris> |
Status: | CLOSED RAWHIDE | QA Contact: | Ben Levenson <benl> |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 8.0 | CC: | stelian |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://sourceforge.net/tracker/?group_id=1306&atid=101306&func=detail&aid=555603 | ||
Whiteboard: | |||
Fixed In Version: | 0.4b33-1 | Doc Type: | Bug Fix |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-05-18 04:04:15 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: |
Description
Christopher R. Wren
2003-04-28 20:32:41 UTC
This could be the right time to update dump to the latest version. 0.4b28 is a year old now, there have been 6 new versions since that one... Stelian. installing dump-0.4b34-1 from http://dump.sourceforge.net seems to have resolved the problem. My incrementals are now sane! Chris Just a note for the curious... Red Hat does not track every new version of an upstream package that might come out over time, and release updated versions of it for existing OS releases. So it is possible that many upstream releases of a given piece of software might occur within a single OS development cycle, and we're not likely to release any updates until the next distribution release comes out. That said, I'll update to the new version in rawhide soon. I just updated the rpm to 0.4b34-1, however it only builds on x86. It does not build on x86_64, so currently, it is less than useful. ;o/ Defering inclusion in rawhide until I have time to investigate the 64bit build failures. for i in compat/lib compat/include common dump restore rmt; do \ (cd $i && make all) || exit 1; \ done make[1]: Entering directory `/home/mharris/rpmbuild/BUILD/dump-0.4b34/compat/lib' gcc -pipe -O2 -g -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -I../.. -I../../compat/include -I../../compat/include -DRDUMP -DRRESTORE -D_BSD_SOURCE -D_USE_BSD_SIGNAL -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b34\" -c -o compaterr.o compaterr.c gcc -pipe -O2 -g -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -I../.. -I../../compat/include -I../../compat/include -DRDUMP -DRRESTORE -D_BSD_SOURCE -D_USE_BSD_SIGNAL -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b34\" -c -o compatglob.o compatglob.c gcc -pipe -O2 -g -Wall -Wpointer-arith -Wstrict-prototypes -Wmissing-prototypes -Wno-char-subscripts -I../.. -I../../compat/include -I../../compat/include -DRDUMP -DRRESTORE -D_BSD_SOURCE -D_USE_BSD_SIGNAL -DLINUX_FORK_BUG -DHAVE_LZO -D_PATH_DUMPDATES=\"/etc/dumpdates\" -D_DUMP_VERSION=\"0.4b34\" -c -o bylabel.o bylabel.c In file included from /usr/include/sys/param.h:42, from bylabel.c:17: /usr/include/sys/types.h:194: conflicting types for `int64_t' /usr/include/sys/types.h:39: previous declaration of `int64_t' make[1]: *** [bylabel.o] Error 1 make[1]: Leaving directory `/home/mharris/rpmbuild/BUILD/dump-0.4b34/compat/lib' make: *** [all] Error 1 error: Bad exit status from /home/mharris/rpmbuild/tmp/rpm-tmp.78488 (%build) RPM build errors: Bad exit status from /home/mharris/rpmbuild/tmp/rpm-tmp.78488 (%build) Oops, just noticed I somehow managed to close this as RAWHIDE. Reopening. dump 0.4b33 compiles fine on x86_64, so the problem is introduced in 0.4b34 dump-0.4b33 compiles on i386, ia64, alpha, x86_64, ppc, s390, s390x so I've decided to put it in rawhide for the time being as I won't have time to investigate the above 64bit build problems for a while. I'll try updating to 0.4b35 when it's released. Closing as fixed in RAWHIDE version dump-0.4b33-1 Mike, I understand Red Hat does not have the ressources to issue bugfixes to every package for the already released OS versions. However, dump has not been updated in a while, and this includes *several* OS development cycles. As for the build problem, I don't have a x86_64 platform to test this on. Moreover nobody reported upstream such a compile failure. Couldn't this be related to a C headers problem ? You compile log shows just that, something incoherent between two system headers: /usr/include/sys/types.h:194: conflicting types for `int64_t' /usr/include/sys/types.h:39: previous declaration of `int64_t' Stelian. Let me try to explain it a bit clearer, so there is no misunderstanding. dump is a priority 3 package in the distribution, so it gets very low priority compared to higher priority packages. When there is a lot of work that needs to be done on priority 1 and 2 packages, then priority 3 packages get less attention, and that might mean that they don't get updated for a while. Updating a package version is not just a matter of building a new RPM. The software must be downloaded, diffs generated between the last version and the current version, and studied perhaps briefly, or perhaps for hours. Changelogs need to be read, copyright notices kept track of, licensing changes investigated, and many other issues that are important. It isn't a 10 minute job. It takes time. That is why dump isn't updated frequently. >As for the build problem, I don't have a x86_64 platform to test this on. It happens on x86_64, ia64, alpha, ppc64, s390x also. Probably on sparc64. Looks like a generic 64bit problem. It might not even be a dump bug though, it could perhaps be a C library header bug, or something else. I'm not sure yet. > Moreover nobody reported upstream such a compile failure. Sorry, I wasn't implying that you should personally investigate this issue yet. I was merely stating that dump 0.4b34 doesn't currently compile successfully, and I don't have time to find out why yet. I've put 0.4b33 in, and it built on all platforms, so that fixes this reported bug, and hopefully a lot of other problems people have reported. I haven't reported it upstream because it just happened, and I don't yet know if it is a bug in dump. I haven't had time to make an adequate assessment. But it doesn't compile in any case, so I can't include it until I do have the time to investigate it, or if someone else does. >Couldn't this be related to a C headers problem? Anything is possible. That is why I haven't claimed it is a dump bug. I only claim that dump doesn't compile on the 64bit architectures I need to compile it on, and that I don't yet know the cause nor have time to try and figure it out currently. >You compile log shows just that, something incoherent between two system >headers: It's one system header - types.h I did look at that header, on the 2 lines specified, and neither line contains anything to do with int64_t, so it is a deeper problem that will require more time to investigate likely. I'm not sure why having the absolute latest version of dump is that much of a mission critical issue though. However, if someone (anyone, not just you) wants the latest release in rawhide faster than I'll have time to devote to it, we accept patches, and appreciate people volunteering to troubleshoot problems. ;o) If I do get a chance to debug this issue, and believe it to be a dump bug, then I'll file a bug report upstream to track it though. Until then though it is just an unknown. My goal was only to solve bug #89835 and I believe that is fixed now. ;o) Thanks I've just added myself to the file and project tracker for "dump" on sourceforge, so I'll be alerted automatically when new versions come out. This may also help to keep dump more updated in the future as well. > My goal was only to solve bug #89835
> and I believe that is fixed now. ;o)
Just for kicks I downgraded to the sourceforge 0.4b33 RPM, form the 0.c4b34,
and it does seem to fix the problem (as it should, according the the CHANGELOG).
Thank you for the fix, and for the peek inside Red Hat proceedures.
Chris
|