ubuntu-phone team mailing list archive

[Chris Wayne <chris.wayne@xxxxxxxxxxxxx>]

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 :) )


On Mon, Feb 10, 2014 at 9:52 AM, Jamie Strandboge <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
> Unsubscribe : https://launchpad.net/~ubuntu-phone
> More help   : https://help.launchpad.net/ListHelp
>
>