On Thu, 2016-08-11 at 16:45 -0600, Leo Arias wrote:
> Hello Mike!
>
> On 2016-08-04 12:58, MikeB wrote:
> >
> > Can someone describe the strategy or point me to an example for
> > including a custom kernel driver as part of a snap?
> >
> > I'm trying to put together a snap that requires several
On 04/08/16 09:16, Christian Ehrhardt wrote:
> Now that doesn't fit in the (otherwise really great) sandboxing into
> ~/snap or /snap.
> Because in this case others programs should be able to pick up these
> files in common paths.
>
> It doesn't really qualify for an interface [3] as I thought to
>
On 09/08/16 18:19, Manik Taneja wrote:
>
> will this allow them to claim the reserved name?
We can allocate a name to a publisher very easily, just need the
authoritative upstream to ask on this mailing list.
In this case we should probably use the new 'collaborators' feature in
the store, which
On Fri, Aug 12, 2016 at 1:35 PM, Mark Shuttleworth wrote:
> Interfaces should actually handle this case very well, as long as both
> sides of the file exchange are predictable. So I can imagine CUPS
> providing an interface to ingest PPDs and a PPD snap that consumes that
> interface making the P
On 12/08/16 08:36, Christian Ehrhardt wrote:
> In the context of the request I was thinking more about snaps on
> classic and how e.g. a "classic" system could pick up those.
> Or turning around the statement: How a snap would ensure things are
> picked up by the "host" in classic.
>
> A generic so
On Fri, Aug 12, 2016 at 5:04 AM, Mark Shuttleworth wrote:
> On 09/08/16 18:19, Manik Taneja wrote:
>
>
> will this allow them to claim the reserved name?
>
>
> We can allocate a name to a publisher very easily, just need the
> authoritative upstream to ask on this mailing list.
>
> In this case w
