Bug 102318 - FYI: failed ASSERT on color report from ender
FYI: failed ASSERT on color report from ender
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
Mike McLean
Depends On:
  Show dependency treegraph
Reported: 2003-08-13 15:54 EDT by R P Herrold
Modified: 2007-04-18 12:56 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-02-23 11:43:06 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description R P Herrold 2003-08-13 15:54:17 EDT
[15:20] <ender> any of you seen this: [root@ender root]# rpm -ivh 
[15:20] <ender> rpm: rpmte.c:518: rpmteColorDS: Assertion `ix < Count' failed. 
[15:20] <ender> Aborted 
[15:22] <orc_orc> ender: rpm colorizing is terra incoginta 'here be monsters' per JBJ -- 
looks as though a selfcheck in that code failed 
[15:22] <ender> any idea why this would start all of a sudden? 
[15:23] <orc_orc> have you bumped rpm since last compile of that   ctcs code? 
[15:23] <ender> well, this is the first attempt at a ctcs rpm. 
[15:23] <ender> the spec is mind numbingly simple.. 
[15:24] <orc_orc> cerberus ctcs-1.2.11.tar.gz 
[15:24] <orc_orc> built for me ... lemme check 
[15:24] <ender> no, this is a complete new spec for it.  I'm making a custom one for 
internal use. 
[15:26] <ender> I'll have to re-examine the spec file to see what could be causing rpm 
to flip out. 
[15:27] <orc_orc> in rebuilding I see a lot of arch construct warnings from that code 
under RHL 9 
[15:28] <ender> I'm not compiling any code. 
[15:29] <ender> it's not the building of the rpm that causes problems, its when I 
attempt to install the rpm that built just fine. 
[15:29] <ender> "built" 
[15:29] <ender> would there be a problem with a Version: being set to 1.3.0pre10 ? 
[15:30] <orc_orc> that was the reason for my RPM question -- I wondered if it was 
compiled under a different rpm version than the install was occurring under, with a 
possible change in colorization bit handling in RPM 
[15:30] <orc_orc> the Version form is valid 
[15:31] <ender> nope, same rpm is used. 
[15:31] <ender> as the user, I issue rpmbuild -ba ctcs.spec, it builds, then as root I -ivh 
it, and boom. 
[15:31] <orc_orc> I am repliacting so I may strace with my older version 
[15:33] <orc_orc> ender: happy to look over -- put SRPM somewhere for anon FTP 
pull please 
[15:34] <ender> orc_orc: http://geek.j2solutions.net/stuff/ctcs-1.3.0pre10-1.src.rpm 
[15:40] <orc_orc> ender: hmmm --  yours appears to be a binary packaging SRPM -- 
with a 'from sources' on the older version build, I show several dependencies popping 
up --  
[15:40] <orc_orc> lemme get the later sources ... 
[15:41] <ender> from sources?  huh? 
[15:42] <ender> yeah, I'm just binary packaging the ctcs stuff.  I grabbed the latest .tgz 
of ctcs from the sf.net website, and since part of the burnin is compiling the code on 
the spot there is no need to distribute precompiled code.  I just don't get why it's 
causing rpm to freak. 
[15:49] <orc_orc> ender: Please try: 
http://www.herrold.com/ctcs-1.3.0pre10-1.i386.rpm   built from:   
[15:50] <orc_orc> ender: you may wish to file a transcript of this for JBJ -- he may want 
to see why the ASSERT failed
Comment 1 R P Herrold 2005-02-23 11:43:06 EST
more than six months old - long since overtaken by events - closing; please
reopen if appropriate

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