Porting hardware testing tool to snappy Ubuntu core

Zygmunt Krynicki zygmunt.krynicki at canonical.com
Tue Jun 2 13:56:31 UTC 2015

Thanks for the replies everyone!

So looking at something I can use in the next few days, rather than
weeks, I see that I should:
- disable confinement for the snap (to experiment with what is available)
- use deb2snap for things we are likely to bundle (everything that
won't become a framework later)
- just assume python3 is there for now
If anything above is incorrect please correct me.

As for frameworks (pulse/udisks) I understand that schedule is not the
easiest thing to ask about so I'll defer that until it becomes
necessary to know.


On Tue, Jun 2, 2015 at 3:09 PM, Ted Gould <ted at ubuntu.com> wrote:
> On Tue, 2015-06-02 at 14:52 +0200, Zygmunt Krynicki wrote:
> Lastly there's the question of language runtimes. I talked to ogra on
> IRC earlier today and he confirmed that all language runtimes will be
> removed down the line. Should we start exploring making each runtime
> that we use and rely on a framework?
> Can't comment as much on the other pieces, but here you should be planning
> to bundle the runtime that you test with into your package. We're working on
> tools to make that easier. If your package uses the same version of, for
> instance Python, as another application the deduplication algorithms should
> take into account the sharing between packages. This way a framework is not
> needed, and if you need to carry a specific patch or a specific version of
> Python you don't need to worry about the framework supporting that.
> Ted
> --
> snappy-devel mailing list
> snappy-devel at lists.ubuntu.com
> Modify settings or unsubscribe at:
> https://lists.ubuntu.com/mailman/listinfo/snappy-devel

More information about the snappy-devel mailing list