Re: Including custom kernel driver with a snap
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 custom kernel > > drivers be installed along with the snap and would like to know the > > "snappy" way of doing this. > Your question comes at a great time :) > There is code, and example and discussion about this here: > https://github.com/snapcore/snapd/pull/1602 > Note that this is an extremely privileged interface since it essentially gives device ownership to the snap and there will be assertions and store checks limiting its use. AFAIK, the snappy way of doing this is still to build a kernel snap with the drivers you want. -- Jamie Strandboge | http://www.canonical.com signature.asc Description: This is a digitally signed message part -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: How to snap packages that provide "extra" files to be used by something else
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 > understand them so far. 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 PPDs available. In the next wave of landings, you'll see the ability to execute code in both snaps when an interface is being connected, allowing you to agree for example on filenames etc. Mark -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: ntopng strict snap published
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 lets multiple accounts (the 'collaborators') push a snap on behalf of the actual publisher. That way the community person who leads the setup of the snap and the CI with Travis and Github integration can shepherd things along until folks upstream have the hang of it. Then we could remove the snapcrafter from the collaborators list, which means the upstream publisher has exclusive ability to release new revisions, once they have a good upstream process for daily builds (edge) and betas and the actual candidate/stable releases too. Mark -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: How to snap packages that provide "extra" files to be used by something else
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 PPDs available. > > In the next wave of landings, you'll see the ability to execute code in > both snaps when an interface is being connected, allowing you to agree > for example on filenames etc. > Ack: In any pure snap setup the interface based solution would have been my way to go for this. And it certainly is the right one. 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 solution for this isn't the most important feature - as it might also break isolation more than we like. So - if considered as a generic feature - this might just end up as one of the constraints for snaps on classic. But for a few common cases (like manpages see bug 1575593 I think we should design and provide something that can be commonly used). Looking forward for the next wave of landings then - maybe the "active interface connect" if we want to call it that way would already provide enough to solve it that way. -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: How to snap packages that provide "extra" files to be used by something else
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 solution for this isn't the most important feature - as it > might also break isolation more than we like. > So - if considered as a generic feature - this might just end up as > one of the constraints for snaps on classic. > But for a few common cases (like manpages see bug 1575593 I think we > should design and provide something that can be commonly used). If the CUPS in the classic environment is a snap, then the snap-to-snap interface will work for classic just as well as all-snap Ubuntu Core. If the CUPS is a deb, then something (could be snapd) would need to know how to handle the interface in enough detail to feed the bits to CUPS. Mark -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
Re: ntopng strict snap published
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 we should probably use the new 'collaborators' feature in the > store, which lets multiple accounts (the 'collaborators') push a snap on > behalf of the actual publisher. That way the community person who leads the > setup of the snap and the CI with Travis and Github integration can > shepherd things along until folks upstream have the hang of it. Then we > could remove the snapcrafter from the collaborators list, which means the > upstream publisher has exclusive ability to release new revisions, once > they have a good upstream process for daily builds (edge) and betas and the > actual candidate/stable releases too. > Thanks Mark. I'll work with Blake and have him setup as the collaborator, until upstream takes over. Cheers, Manik -- Snapcraft mailing list Snapcraft@lists.snapcraft.io Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/snapcraft
