Bug 837877

Summary: JON Agent RPM Errata Failure(s): Elfinit, Binary stripping, Exec shield, IPV6
Product: [JBoss] JBoss Operations Network Reporter: Mike Foley <mfoley>
Component: AgentAssignee: RHQ Project Maintainer <rhq-maint>
Status: CLOSED DEFERRED QA Contact: Mike Foley <mfoley>
Severity: medium Docs Contact:
Priority: unspecified    
Version: JON 3.1.0CC: asantos, djorm, loleary, mjc, myarboro, snegrea, thoger
Target Milestone: ---   
Target Release: JON 3.2.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 838596 838601 838603 838605 (view as bug list) Environment:
Last Closed: 2014-01-10 15:25:32 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 838596, 838601, 838603, 838605    
Bug Blocks: 837381    
Attachments:
Description Flags
errata failures for elfinit
none
errata failure for binary stripping
none
errata failure for ipv6
none
errata failure for execshield none

Description Mike Foley 2012-07-05 16:42:11 UTC
https://errata.devel.redhat.com/rpmdiff/show/62412?result_id=1141638

Document the waiver, or fix.

Comment 1 Mike Foley 2012-07-05 18:46:48 UTC
Created attachment 596470 [details]
errata failures for elfinit

Comment 2 Mike Foley 2012-07-05 18:47:25 UTC
Created attachment 596471 [details]
errata failure for binary stripping

Comment 3 Mike Foley 2012-07-05 18:47:56 UTC
Created attachment 596472 [details]
errata failure for ipv6

Comment 4 Mike Foley 2012-07-05 18:48:37 UTC
Created attachment 596474 [details]
errata failure for execshield

Comment 5 Stefan Negrea 2012-07-06 21:11:35 UTC
All these failures should be waived because the binary libraries are distributed (and have been distributed) in the regular agent packaging without any problems or issues raised. The files are part of the typical agent installation payload. A more detailed explanation for each failure or warning is presented below.


1) Elflint - Failure

Example failure message: 
libaugeas.so within payload for noarch is an Intel 80386 ELF file

Waiver explanation:
This failure is triggered because the agent RPM is marked as .noarch while the library is architecture specific. The RPM includes libraries for all supported architectures. This is a non-issue because the agent will determine which library to use at runtime.


2) Binary Stripping - Failure

Example failure message: 
libsigar-amd64-linux.so is not stripped of DWARF data on noarch

Waiver explanation:
The error message means that the particular library has not been stripped of debug information. The only side effects are larger libraries and the potential to reveal more information than it should about code structure. Since the library is external to the project, the only course of action is to report the problem to the respective community and update the library once fixed in future JON releases.

3) Execshield - Failure

Example failure message:
Program built without GNU_STACK: /usr/share/jboss-on-3.1.0.GA/agent/lib/libsigar-x86-linux.so on noarch

Waiver explanation:
This failure means that the library does not contain a GNU_STACK line but it requires executable stacks. Since the library is external to the project, the only course of action is to report the problem to the respective community and update the library once fixed in future JON releases.


4) IPV6 - Warning

Example failure message:
libsigar-amd64-linux.so on noarch uses function inet_addr, which may impact IPv6 support

Waiver explanation:
This warning means that the library is using deprecated symbols that could affect IPV6 support. Since the library is external to the project, the only course of action is to report the problem to the respective community and update the library once fixed in future JON releases.

Comment 6 Mike Foley 2012-07-09 14:45:58 UTC
cloned elfinit issue into a new BZ 
https://bugzilla.redhat.com/show_bug.cgi?id=838596
for consideration in JON 3.2

Comment 7 Mike Foley 2012-07-09 14:48:59 UTC
cloned binary stripping issue into a new BZ
https://bugzilla.redhat.com/show_bug.cgi?id=838601

Comment 8 Mike Foley 2012-07-09 14:51:08 UTC
cloned exec shield issue into a new BZ 

https://bugzilla.redhat.com/show_bug.cgi?id=838603

Comment 9 Mike Foley 2012-07-09 14:54:00 UTC
cloned 4th issue into

https://bugzilla.redhat.com/show_bug.cgi?id=838605

Comment 10 David Jorm 2012-07-12 05:42:42 UTC
It seems that the approach here does not entirely fit with our standard RPM packaging paradigm, and that is leading to these failures. In summary, this package needs to be re-defined with the following changes:

* Take out binary libs from upstream (i.e. libsigar), package them properly and build them from source using the required compiler flags
* Make this an arch-specific RPM, presumably i386
* Remove all binary components not for that arch

To address each failure:

1) Elflint - Failure

arch-specific binaries should not be in a noarch RPM. A noarch RPM should only contain truly architecture independent components such as shell scripts and java classes, not binaries for all architectures.

2) Binary Stripping - Failure, 3) Execshield - Failure, 4) IPV6 - Warning

libsigar should be built from source using the appropriate compiler flags, and presumably packaged a distinct RPM (but I am not too familiar with the rules for what qualifies as a distinct RPM).

Comment 11 Tomas Hoger 2012-08-01 09:41:17 UTC
AFAICS, the attempt here is to provide RPM packages for JON agent that can be installed on RHEL-6 i386 and x86_64.  Most / all of this is failing on embedded libraries - sigar and augeas.

Both of these libraries are included in main RHEL-6 and hence we should try to use those versions.  Using them may avoid the need for building them for JON at all.  And may result in proper .noarch rpm.

As these RPMs are only to be used on RHEL hosts, there's no reason to include non-Linux libraries (Solaris, HP-UX, FreeBSD).  Additionally, it may be possible to avoid shipping few jars that are also provided by RHEL rpms.