[OE-core] [PATCH 1/3] libaudit: new package

Thu Feb 28 19:44:57 UTC 2013

On Thu, 2013-02-28 at 10:57 -0800, Saul Wold wrote:
> On 02/27/2013 08:45 PM, Tom Zanussi wrote:
> > On Wed, 2013-02-27 at 20:32 -0800, Saul Wold wrote:
> >> On 02/27/2013 07:00 AM, tom.zanussi at linux.intel.com wrote:
> >>> From: Tom Zanussi <tom.zanussi at linux.intel.com>
> >>>
> >>> Add libaudit, used by system call auditing applications.  From the
> >>> sources:
> >>>
> >>>    "The audit package contains the user space utilities for storing and
> >>>    searching the audit records generate by the audit subsystem in the
> >>>    Linux 2.6 kernel."
> >>>
> >>> Signed-off-by: Tom Zanussi <tom.zanussi at linux.intel.com>
> >>> ---
> >>>    .../libaudit/libaudit/build-lib-only.patch         |  33 ++
> >>>    .../libaudit/libaudit/fix-host-gen.patch           | 461 +++++++++++++++++++++
> >>>    meta/recipes-support/libaudit/libaudit_2.2.2.bb    |  25 ++
> >>>    3 files changed, 519 insertions(+)
> >>>    create mode 100644 meta/recipes-support/libaudit/libaudit/build-lib-only.patch
> >>>    create mode 100644 meta/recipes-support/libaudit/libaudit/fix-host-gen.patch
> >>>    create mode 100644 meta/recipes-support/libaudit/libaudit_2.2.2.bb
> >>
> >>>
> >> <SNIP>
> >>
> >>
> >>> diff --git a/meta/recipes-support/libaudit/libaudit_2.2.2.bb b/meta/recipes-support/libaudit/libaudit_2.2.2.bb
> >>> new file mode 100644
> >>> index 0000000..e28b619
> >>> --- /dev/null
> >>> +++ b/meta/recipes-support/libaudit/libaudit_2.2.2.bb
> >>> @@ -0,0 +1,25 @@
> >>> +DESCRIPTION = "libaudit is the dynamic library needed for applications to use the audit framework."
> >>> +SECTION = "libs"
> >>> +AUTHOR = "Steve Grubb <sgrubb at redhat.com>"
> >>> +HOMEPAGE = "http://people.redhat.com/sgrubb/audit/"
> >>> +LICENSE = "LGPLv2+"
> >>> +LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
> >>> +PR = "r0"
> >>> +
> >>> +SRC_URI = "http://people.redhat.com/sgrubb/audit/audit-${PV}.tar.gz \
> >>> +           file://build-lib-only.patch \
> >>> +           file://fix-host-gen.patch \
> >>> +          "
> >>> +
> >>> +SRC_URI[md5sum] = "6641fde111cf5dfda6d4282ab8410df5"
> >>> +SRC_URI[sha256sum] = "8bc2b45a5f08f5df6cebcd5543f24b7e68e28b64da4b23f08de2c6616384302b"
> >>> +
> >>> +S = "${WORKDIR}/audit-${PV}"
> >>> +
> >>> +inherit autotools
> >>> +
> >>> +EXTRA_OECONF = "--disable-dependency-tracking --disable-listener"
> >>> +
> >>> +do_configure() {
> >>> +	       oe_runconf
> >>> +}
> >>>
> >> Is this do_configure really needed?  Does the autotools default not work
> >> correctly?  And if not why not?
> >
> > This is to avoid the autoreconf step, which ends up overwriting the
> > lib/Makefile.in changes when it regenerates it from lib/Makefile.am.
> >
> > The Makefile.in is shipped with the source tarball, so I modified it
> > directly instead of complicating things by trying to get autoreconf to
> > generate the correct Makefile for the target part of the build vs these
> > specific changes to Makefile.in for the set of programs generated to run
> > on the host.
> >
> 
> Tom,
> 
> I understand your approach here and while it has good intentions, is not 
> the right way to go about this.  We want to enable upstream packages to 
> cross compile (if they are open to the idea). So changing the 
> Makefile.am would be the right way to do this and allow the standard 
> automake and autoreconf to do their work.  This would also allow the 
> patches to be possibly accepted up stream.
> 

OK, makes sense, I understand - I did actually try digging into this and
to do it by targeting Makefile.am, but got bogged down in the details of
figuring out how to get everything generated properly for the target and
these special cases of these other programs generated for the host.

Also, any patch that would likely be accepted upstream would have to
address everything in the audit package, not just the small libaudit
part that this recipe is interested in.   It doesn't seem worth the work
to make it all cross-compileable it in order to simply to enable a
single perf feature.

It may be that not much more is needed, but I did notice the same types
of problems in other subdirs of the package when I neglected to filter
them out.  In any case, I will take another look and consider some of
the things you mention below...

> I understand there are examples of this type of patching in OE-Core, 
> that does not mean they are good examples and they should probably be 
> looked into for fixing also.
> 
> I know you have put effort in here, and we want to make sure the patches 
> are correct and good example moving forward.
> 
> For example in the first build-lib-only patch you can just edit the 
> SUBDIRS line to include lib.
> 

Right, fixing the top-level Makefile.am was easy - changing the SUBDIRs
line there was what I did in the -v0 branch, the more problematic case
is the Makefile.am in /lib... 

> For the larger patch, are you selectively changing CCLD and CFLAGS or is 
> it through out?  You should probably build these -native and use them 
> instead of trying to tweak around the target build.
> 

Selectively, just for the gen_* programs which are used to generate
tables and structs on the host.

I'll try the -native route instead, which does make sense as an
alternative...

Thanks for the input..

Tom

> We can discuss it further as needed.
> 
> Thanks
> 	Sau!
> 
> > Tom
> >
> >>
> >> Sau!
> >>
> >
> >
> >
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core