<html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <div class="moz-cite-prefix">Le 31/01/2017 à 20:35, Jamie Strandboge a écrit : </div> <blockquote cite="mid:1485891337.10013.193.camel@canonical.com" type="cite"> <pre wrap="">On Tue, 2017-01-31 at 17:04 +0100, Didier Roche wrote: </pre> <blockquote type="cite"> <pre wrap="">Le 30/01/2017 à 15:39, Jamie Strandboge a écrit : </pre> <blockquote type="cite"> <pre wrap="">On Mon, 2017-01-30 at 08:47 -0500, Stephen M. Webb wrote: </pre> <blockquote type="cite"> <pre wrap="">On 2017-01-30 01:56 AM, Spencer Parkin wrote: </pre> </blockquote> <pre wrap="">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? </pre> </blockquote> <pre wrap="">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 perception? </pre> </blockquote> <pre wrap="">'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 you confirm?</pre> </blockquote> Ah got it :) So yes, you can add this path. Note that we'll have the same denials if others paths (like /usr/loca/share/glib-2.0/schemas) happens to have some schema files for whatever reason. So, I don't know if you should add all paths (see below) or just the one logically containing schemas. Not that the first element of XDG_DATA_DIRS is based on session name (here, under unity7, we are in the ubuntu session, hence /usr/share/ubuntu, unity8 would be something like /usr/share/unity8 for now…), making this more complex. We don't expect for now (contrary to gconf days), for those to have schema files. <blockquote cite="mid:1485891337.10013.193.camel@canonical.com" type="cite"> <pre wrap=""> </pre> <blockquote type="cite"> <pre wrap="">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 /usr/share/ubuntu:/usr/share/gnome:/usr/local/share/:/usr/share/:/var/lib/snap d/desktop As you can see, quite some paths are involved (even if in practice, only /usr/share/glib-2.0/schemas/ would exist in general). </pre> </blockquote> <pre wrap=""> I'll keep these in mind. </pre> <fieldset class="mimeAttachmentHeader"></fieldset> </blockquote> </body> </html>