[apparmor] [patch] make parser's definition of allowed var names consistent

Steve Beattie steve at nxnw.org
Thu Mar 31 22:24:35 UTC 2011

On Thu, Mar 31, 2011 at 11:14:55PM +0200, Christian Boltz wrote:
> Hello,
> Am Donnerstag, 31. März 2011 schrieb Steve Beattie:
> > On Thu, Mar 31, 2011 at 08:12:32PM +0200, Christian Boltz wrote:
> > > Am Mittwoch, 30. März 2011 schrieb Christian Boltz:
> > Trunk has the shortcut lp:apparmor (or alternatively
> > bzr+ssh://bazaar.launchpad.net/+branch/apparmor/), so you can do:
> > 
> >   bzr checkout lp:apparmor
> OK, that worked (after finding out how to set a sane userid in launchpad 
> and where the SSH key upload is hidden - is it really only linked on 
> some help.launchpad.net pages?

Bah, sorry, I meant to mention the ssh key bit. You can
see what keys you have registered from your launchpad
home page https://launchpad.net/~[YourLPID] (in your case
https://launchpad.net/~cboltz ); the direct link for adding/removing
is https://launchpad.net/~[YourLPID]/+editsshkeys .

There is support for checking out a branch via http access rather
than over bzr+ssh, but then you're strictly working as an independent
distributed branch.

> I'd prefer to use a separate (sub)directory so that
> a) apparmor.vim stuff doesn't conflict with something else
> b) I don't have too many (unrelated) files lying around
> What about utils/apparmor_vim/ ?

Maybe just utils/vim/ ? The 'apparmor_' bit is just redundant for a
directory name.

> To give you an idea: my current directory with apparmor.vim looks like 
> this (with some comments on what the files are/do):
> directly related to apparmor.vim:
> -rw-r--r-- 1 cb users 15519 28. Mär 13:23 apparmor.vim
> -rw-r--r-- 1 cb users 11689 28. Mär 13:23 apparmor.vim.in
> -rwxr-xr-x 1 cb users  5322 11. Jan 16:46 make
> -rw-r--r-- 1 cb users    53 11. Jan 16:44 Makefile

What's the difference between make and Makefile here? Is make a shell
script that does the actual work?

> some test profiles and sniplets - some with valid, some with 
> intentionally broken syntax (to test detection of invalid rules):
> -rw-r--r-- 1 cb users  1456 25. Sep 2008  
>                                  test_aa_abstractions_authentication
> -rw-r--r-- 1 cb users 15456  1. Feb 00:01 test_usr.sbin.httpd2-prefork
> -rw-r--r-- 1 cb users   902 25. Sep 2008  test_usr.sbin.identd
> -rw-r--r-- 1 cb users  3473  1. Feb 22:31 test_usr.unattached

A tests/ (or similar) subdirectory below vim/ probably makes
sense for those. (I wonder if we could rig up something like
http://blog.nix.is/testing-vim-syntax-files to automate testing.)

> historical versions (not worth to be pushed to bzr IMHO):


> openSUSE-related script to create a fire-and-forget branch of vim:
> (not sure if I should put it to bzr)
> -rwxr-xr-x 1 cb users    50 31. Jan 23:59 osc-branch-and-checkout-vim

I'm not terribly opposed to having infrastructure-type stuff in the
tree, even if it's not useful to many people.

> > Though when thinking about the issue of auto-generating stuff like
> > the network protocols, I did have the thought that we could possibly
> > build it when generating the tarball for snapshot or release (like we
> > currently do for the small amount of autoconf stuff that we have). It
> > would require whoever does the release to have the most recent kernel
> > headers installed, but that's doable, I think.
> Rebuilding the list of network protocols etc. when generating a tarball 
> is a very good idea to keep them up-to-date. 
> There should also be an easy way to generate these lists so that I can 
> build apparmor.vim locally without problems. In other words: the same 
> script that you use when generating the tarball ;-)

Sure. Really, all that would happen is that the top level 'make setup'
target would invoke make (or make apparmor.vim) in the utils/vim/

Steve Beattie
<sbeattie at ubuntu.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/apparmor/attachments/20110331/8cca2e6c/attachment.pgp>

More information about the AppArmor mailing list