Bug 151527

Summary: Assertion failure with %dev entry
Product: [Fedora] Fedora Reporter: Ville Skyttä <scop>
Component: rpmAssignee: Paul Nasrat <nobody+pnasrat>
Status: CLOSED UPSTREAM QA Contact: Mike McLean <mikem>
Severity: medium Docs Contact:
Priority: medium    
Version: 4CC: anvil, fedora, herrold, nobody+pnasrat
Target Milestone: ---Keywords: Regression
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-10-25 22:33:26 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:
Attachments:
Description Flags
reproducer specfile
none
handle %dev markers in spec files none

Description Ville Skyttä 2005-03-18 22:21:53 UTC 
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 ?? ()
Comment 1 Ville Skyttä 2005-03-18 22:21:54 UTC 
Created attachment 112146 [details]
reproducer specfile
Comment 2 Jeff Johnson 2005-03-19 18:36:54 UTC 
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.
Comment 3 Ville Skyttä 2005-03-19 19:26:42 UTC 
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.
Comment 4 Jeff Johnson 2005-03-19 19:57:06 UTC 
Created attachment 112151 [details]
handle %dev markers in spec files
Comment 5 Jeff Johnson 2005-03-19 20:00:38 UTC 
rpmbuild is not "dumping core", this is a deliberate
assert failure to control for unclassified tag
content inf packages.
Comment 7 Thorsten Leemhuis 2005-08-21 15:20:24 UTC 
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?
Comment 8 Dams 2005-08-22 13:34:43 UTC 
/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 ?
Comment 9 Thorsten Leemhuis 2005-10-29 16:13:27 UTC 
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.