All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Grubb <sgrubb@redhat.com>
To: burn@swtf.dyndns.org
Cc: linux audit <linux-audit@redhat.com>
Subject: Re: audit 2.3.6 released
Date: Mon, 14 Apr 2014 20:11:12 -0400	[thread overview]
Message-ID: <1853896.aYEMLF8qDN@x2> (raw)
In-Reply-To: <1397353906.21581.14.camel@swtf.swtf.dyndns.org>

On Sunday, April 13, 2014 11:51:45 AM Burn Alting wrote:
> A patch is attached that addresses this.
> 
> Essentially the modification 
> - notices if we identify an audit.log file to use but we do not find the
> recorded audit event in that log file and so report an error (to stderr)
> and return a new exit code (12)
> - allows checkpointing to only use the recorded time from the checkpoint
> file for comparisons.

I'd like to look at these two pieces separately. Let's have 1 bug/feature per 
patch. This way if something looks good, it can be applied immediately. 
Whereas if something needs more discussion, it would block application of the 
part that is good.


> You will note that the patch also contains changes to swig/audit.py.
> Although this file is automatically generated, it is part of the 2.3.6
> release ... should it be?

I suppose it should be. What is in the release is decided by 
automake/autoconf. If there are any mistakes in the Makefile.am file, I would 
take a patch.


> I also note that a lot of Makefile.in's are also part of the release. Again,
> should these automatically generated files be part of the release?

The audit package release is done by a script that pretty much does the 
following (its way more complicated than this, but this is the essential 
pieces):

mkdir audit
cd audit
svn co http://svn.fedorahosted.org/svn/audit/trunk .
./autogen.sh
./configure
make -j 8 distcheck

If it finishes saying it created the tar ball, I send it to rawhide to make 
sure it builds on a current OS. If that is also successful, then I push it to 
my people page and then commit a branch in svn. I also run the development 
audit package on all my systems during the whole development cycle to make 
sure bugs are fixed, nothing new shows up, and its builds under normal 
conditions.

So, anything that is there, is because autotools think it should be there 
unless I made a mistake in a Makefile.am. :-) Patches are welcome.

Thanks,
-Steve

  reply	other threads:[~2014-04-15  0:11 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-11 21:17 audit 2.3.6 released Steve Grubb
2014-04-13  1:51 ` Burn Alting
2014-04-15  0:11   ` Steve Grubb [this message]
2014-04-18  2:08     ` Burn Alting
2014-04-23 18:51       ` Steve Grubb
2014-04-18  2:36     ` Burn Alting

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1853896.aYEMLF8qDN@x2 \
    --to=sgrubb@redhat.com \
    --cc=burn@swtf.dyndns.org \
    --cc=linux-audit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.