Bug 151527 - Assertion failure with %dev entry
Assertion failure with %dev entry
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
: Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-18 17:21 EST by Ville Skyttä
Modified: 2007-11-30 17:11 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-25 18:33:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
reproducer specfile (304 bytes, text/plain)
2005-03-18 17:21 EST, Ville Skyttä
no flags Details
handle %dev markers in spec files (4.16 KB, patch)
2005-03-19 14:57 EST, Jeff Johnson
no flags Details | Diff

  None (edit)
Description Ville Skyttä 2005-03-18 17:21:53 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
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 17:21:54 EST
Created attachment 112146 [details]
reproducer specfile
Comment 2 Jeff Johnson 2005-03-19 13:36:54 EST
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 14:26:42 EST
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 14:57:06 EST
Created attachment 112151 [details]
handle %dev markers in spec files
Comment 5 Jeff Johnson 2005-03-19 15:00:38 EST
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 11:20:24 EDT
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 09:34:43 EDT
/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 12:13:27 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.