Jamie Nguyen
dysco****@gmail*****
Thu Dec 23 20:31:57 JST 2010
Tetsuo Handa wrote: >> Yes, when the firefox related lines go after reject_003.log then it >> doesn't work. If I move the firefox lines before then it works fine. > > This is because evaluation stops at first chunk which matched all conditions. > Chunks with stricter conditions have to be defined prior to chunks with looser > conditions. OK, I added extra instructions in auditd.conf . > Merge window for 2.6.37 was already closed. Thus, 2.6.37 remains TOMOYO 2.3. > Merge window for 2.6.38 will open in January, but it is too soon to reflect > TOMOYO 1.7 -> TOMOYO 1.8 changes. Thus, 2.6.38 will remain TOMOYO 2.3. > 2.6.39 might reflect TOMOYO 1.7 -> TOMOYO 1.8 changes, but that is not now. If my understanding is correct, your workflow is something like this (subversion locations have been guessed): (1) Merge window coming soon (2) Set up new subversion directory to place major patches (trunk/2.x.x/tomoyo-lsm/patches) (3) When ready, create tag for major patches (tag/lkml) (4) Merge window opens (5) Send patches (from tags/lkml) to LKML (6) Merge window closes (7) Continue working on patches for bugfixes etc. (trunk/2.x.x/tomoyo-lsm/patches) (8) When ready, create tag for bug fix patches (tags/lkml) (9) Send patches (from tags/lkml) to LKML (10) Bugfixes incorporated into Linux kernel 2.6.x-rc releases (11) Stable kernel 2.6.x released (12) Repeat steps 7-9 for bugfixes to stable kernels 2.6.x.x (13) Repeat all steps when close to next merge window Is this correct? > Excuse me, I want to confirm. Do you agree with forcing users to use pipe or > redirection when using ccs-loadpolicy ? Yes, I agree. > Sorry, commit 4238 needs reconsideration. OK, I have changed to reflect your advice and included an extra example in man page. Kind regards
TOMOYO
Fork