glGetUniformLocation fails in confinement mode
jamie at canonical.com
Tue Jan 31 19:35:37 UTC 2017
On Tue, 2017-01-31 at 17:04 +0100, Didier Roche wrote:
> Le 30/01/2017 à 15:39, Jamie Strandboge a écrit :
> > On Mon, 2017-01-30 at 08:47 -0500, Stephen M. Webb wrote:
> > > On 2017-01-30 01:56 AM, Spencer Parkin wrote:
> > While harmless, it is also confusing. I'm not super familiar with the
> > desktop
> > part and wonder how we can improve this. Didier or Seb, would the
> > bootstrapping
> > process work ok if we allowed read on the /usr/share/glib-2.0/schemas/
> > directory
> > in the unity7 (and maybe the x11) transitional classic interfaces?
> The issue is indeed that there is classic confinement vs core only. I
> thought that it makes sense to read all traditional glib schema paths,
> test that they exists, and if they exist, compile the gsetting schemas
> alongside the snap specific ones.
> /usr/share/glib-2.0/schemas/, as Jamie told, don't exist on core, so we
> just skip it and don't have that denial. On classic however, it does.
> I'm surprised thought hat there is even a denial: I thought classic gave
> you access to your whole host system and this kind of things won't
> happen, do you mind giving some precisions Jamie to fix my twisted
'classic' is an overloaded term. There is 'classic distro' (eg Ubuntu Desktop)
and there is 'classic confinement' (ie, 'confinement: classic'). What the above
denial is about is 'confinement: strict' on classic Ubuntu and my question was
if the desktop part would work ok if we allowed /usr/share/glib-2.0/schemas/
with 'confinement: strict'. Based on your comment, it sounds like 'yes', but can
> For the paths we are checking, we are basing ourself on $XDG_DATA_DIRS,
> appending glib-2.0/schemas to each of them.
> On 16.04 LTS, this is:
> $ echo $XDG_DATA_DIRS
> As you can see, quite some paths are involved (even if in practice, only
> /usr/share/glib-2.0/schemas/ would exist in general).
I'll keep these in mind.
Jamie Strandboge | http://www.canonical.com
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: This is a digitally signed message part
More information about the Snapcraft