Red Hat Bugzilla – Bug 151527
Assertion failure with %dev entry
Last modified: 2007-11-30 17:11:02 EST
FC4test1/Rawhide, rpm-build-4.4.1-7, doing a "rpmbuild -bb t.spec" with the
attached specfile gives me:
$ rpmbuild -bb t.spec
Processing files: t-1-1
`/home/scop/rpmbuild/tmp/t-1-1-buildroot-scop/etc/udev/devices/nvram' (No such
file or directory)
rpmbuild: rpmfc.c:1229: rpmfcClassify: Assertion `ftype != ((void *)0)' failed.
Aborted (core dumped)
The same specfile works and produces the expected result on FC3, rpm-build-4.3.2-21.
Strangely enough, if I change the path in the %files section to /dev/nvram, it
works also with the newer rpm.
#0 0x005b07e2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1 0x005f5a7c in raise () from /lib/tls/libc.so.6
#2 0x005f71c8 in abort () from /lib/tls/libc.so.6
#3 0x005eec9e in __assert_fail () from /lib/tls/libc.so.6
#4 0x005439ff in rpmfcClassify (fc=0x83ec2a0, argv=0x83e8f30) at rpmfc.c:1229
#5 0x00545f66 in rpmfcGenerateDepends (spec=0x83d4668, pkg=0x83ea910) at
#6 0x0053681d in processBinaryFiles (spec=0x83d4668, installSpecialDoc=4,
test=0) at files.c:2474
#7 0x00530c01 in buildSpec (ts=0x83d4430, spec=0x83d4668, what=159, test=0) at
#8 0x0804a774 in ?? ()
#9 0x083d4430 in ?? ()
#10 0x083d4668 in ?? ()
#11 0x0000009f in ?? ()
#12 0x00000000 in ?? ()
Created attachment 112146 [details]
Yep. The assert is avoided by not classifying paths
that start "/dev/", not the case with /etc/udev/devices/nvram.
I question the need and use of packaging devices in random packages,
but that's your packaging style call,, not mine.
I'm not happy with the %dev creation in question, and I'm looking for
alternatives. But this bug report is about rpmbuild dumping core, not packaging
Created attachment 112151 [details]
handle %dev markers in spec files
rpmbuild is not "dumping core", this is a deliberate
assert failure to control for unclassified tag
content inf packages.
still happens with FC4 (rpm-build-4.4.1-22) -- updateing version in this bugreport.
Any chance we get this fixed? Or does anybody know a work-around that works on a
/etc/udev/devices/ is a standard place to create devices, isnt it ?
all devices in /etc/udev/devices are created at udevd start, as far as I know.
Can we have an update for this problem, please ?
nasrat, any chance to get the fix for this bug shipped in a updated rpm for FC4
-- I soon might have a package in extras where I otherwise have to workaround
this bug. I also have a package in a 3rd-party repo that has ugly workarounds
due to this bug -- I'd like to get rid of those.