[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):
Agreed.
> 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/
directory.
--
Steve Beattie
<sbeattie at ubuntu.com>
http://NxNW.org/~steve/
-------------- 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