ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

It shouldn't live in /custom, the custom tarball is only for
carrier-specific customizations.  TBH it doesn't matter to me in which
dir/partition this stuff lives, as long as it's not shipped in the rootfs
image.


On Mon, Feb 10, 2014 at 10:20 AM, Jamie Strandboge <jamie@xxxxxxxxxxxxx>wrote:

> On 02/10/2014 08:56 AM, Chris Wayne wrote:
> > Jamie,
> > Thanks for reviving this, it definitely needs more action.
> >
> >
> > I don't think the plan should be to move it into a different deb package
> shipped
> > in the rootfs.  I thought the plan was to ship everything
> device-specific in the
> > device tarball? (That is after all, the whole purpose of this thread :) )
> >
> I don't have a strong opinion on this (though it sounds like others
> might), but
> for apparmor, I just need a decision on the directory and then I can move
> the
> existing hardware-specific policy to it. Do note, this directory must
> exist and
> will need to be created by apparmor-easyprof-ubuntu, which means that this
> directory will exist on all systems with apparmor-easyprof-ubuntu
> installed (ie,
> desktop systems with the sdk installed now and all desktop systems once we
> move
> to unity8).
>
> Would it be acceptable to make (some part of)
> /usr/share/apparmor/hardware/*
> read/write via /etc/system-image/writable-paths so the device tarball can
> unpack
> there or is there some hard requirement that it must live in /custom? (I'm
> not
> super keen on /custom on desktop systems, but maybe that is exactly what we
> want-- OEMs for desktop system could ship policy there too)
>
> >
> > On Mon, Feb 10, 2014 at 9:52 AM, Jamie Strandboge <jamie@xxxxxxxxxxxxx
> > <mailto:jamie@xxxxxxxxxxxxx>> wrote:
> >
> >     On 01/17/2014 07:32 PM, Steve Langasek wrote:
> >     > On Fri, Jan 17, 2014 at 05:51:27PM +0000, John McAleely wrote:
> >     >> On 17/01/14 17:04, Oliver Grawert wrote:> hi,
> >     >>> Am Freitag, den 17.01.2014, 16:47 +0000 schrieb John McAleely:
> >     >>>> I think that is a genie we would rather not let out of the
> bottle. As
> >     >>>> you note, there are already 7 cases where device specifics are
> needed. I
> >     >>>> assume that as we gain more devices, that number will grow,
> even if we
> >     >>>> also act to add generic abstractions into the common parts to
> manage
> >     >>>> those device specifics.
> >     >
> >     >>> well, as you can see from the discussion none of these 7 files
> *need* to
> >     >>> be in the rootfs tarball ... the bluetooth one should be chipset
> >     >
> >     >> Understood & agreed. I think I'm surprised that we are adding
> stuff to
> >     >> the android tarball in any of these cases, rather than building in
> >     >> some sort of Ubuntu device specific tarball/image/partition/deb.
> >     >
> >     >> I think that most of these will be examples of Ubuntu choosing to
> use
> >     >> a different userland stack to Android, and asking the Android
> tarball
> >     >> to carry device configs for those sits oddly with me.
> >     >
> >     > To clarify, what we're talking about here is the android source
> package, not
> >     > the android tarball per se.  The android package in Ubuntu is the
> point
> >     > where we gather up the contents for the recovery and boot
> partitions, and
> >     > the loopback filesystem used for the container, all of which are
> currently
> >     > android based.  But we don't necessarily need to add these configs
> to an
> >     > android tree in order to have them included in the correct
> partitions.  If
> >     > it's preferable, we could certainly have them live in the
> lxc-android-config
> >     > source package, and have that spit out a binary package which the
> android
> >     > source depends on when it builds its images.  (But then you still
> have the
> >     > two-stage build process to contend with, which involves rebuilding
> the
> >     > android package anyway, at least until we start dealing with
> non-android
> >     > devices.)
> >     >
> >
> >     Now that the android 4.4 stack is is being tested, we are seeing
> more of these
> >     hardware specific accesses. I feel like the thread sorta died
> without clear
> >     direction on how to move forward. The current existing plan is to:
> >
> >      * have apparmor-easyprof-ubuntu ship the
> /usr/share/apparmor/hardware/*
> >        directories (so profiles can reference it)
> >      * move the existing policy from /usr/share/apparmor/hardware/*/*
> into
> >        lxc-android-config as described in the bug[1] and previously on
> this list[2]
> >
> >     Is this still the plan of record or is something changing?
> >
> >     [1]
> https://bugs.launchpad.net/ubuntu/+source/lxc-android-config/+bug/1197133
> >     [2]
> https://lists.ubuntu.com/archives/ubuntu-devel/2013-September/037654.html
> >
> >
> >     --
> >     Jamie Strandboge                 http://www.ubuntu.com/
> >
> >
> >     --
> >     Mailing list: https://launchpad.net/~ubuntu-phone
> >     Post to     : ubuntu-phone@xxxxxxxxxxxxxxxxxxx
> >     <mailto:ubuntu-phone@xxxxxxxxxxxxxxxxxxx>
> >     Unsubscribe : https://launchpad.net/~ubuntu-phone
> >     More help   : https://help.launchpad.net/ListHelp
> >
> >
>
>
> --
> Jamie Strandboge                 http://www.ubuntu.com/
>
>