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 error: magic_file(ms, "/home/scop/rpmbuild/tmp/t-1-1-buildroot-scop/etc/udev/devices/nvram") failed: cannot open `/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. gdb backtrace: #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 rpmfc.c:1577 #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 build.c:333 #8 0x0804a774 in ?? () #9 0x083d4430 in ?? () #10 0x083d4668 in ?? () #11 0x0000009f in ?? () #12 0x00000000 in ?? ()
Created attachment 112146 [details] reproducer specfile
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 style issues.
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 unmodified FC4?
/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.