We have been using meta-snappy in our project and have made a number of improvements in our private fork. I am looking to consolidate those changes and make them part of the https://github.com/morphis/meta-snappy project.
I think it might make sense to move that repository under a neutral name OR make that part of the snapcore github project. We basically want to make sure that a single project goes forward and sees active development so that effort isn’t duplicated.
We have also done work to enable snapd to work on a read-only rootfs on a Yocto based system, using overlayfs and bind-mounts. So I think that is something that might be of interest to people as well.
offtopic: We also have built our own snap store, a cli tool to install/update snaps from our store, hopefully going forwards we’ll open source that as well
We’ll need a new repo under github.com/snapcore. I’ll talk to @mvo to see what can be done about that.
Would you be willing to act as one of the maintainers of that repository?
Yes, we depend on it and I would love to help maintain it
I’ve played with the github version of meta-snappy and would be interested in your improvements. Are you allowed to share the URL where one can look at it?
I’ve talked to @mvo and we have an agreement to move the repository under github.com/snapcore. There’s a question about naming, snappy is something we have moved away from, there’s still some files that use snappy, but more fequently it’s snap, snaps, and snapd.
How about we use one of those names:
0 voters
or something else?
Go with meta-snapd … normally, I’d say meta-snap but there is already a company named “Snap” and I don’t want to chance conflicting with it or having people misunderstand.
rday
I’d go with meta-snap. “snap package” is a common name that people know about this format. This repository is supposed to be more than just packaging snapd for yocto. It’s going to include recipes on how to “seed” snaps into a Yocto image, include recipes for supporting read-only rootfs as well.
Most of all, it’s awesome that we are finally moving this project under snapcore, I hope it will pave way for snapd adding automated integration tests for Yocto as well
To save time, you can start with this updated layer if you want:
I updated to snapd-2.54.4, and cleaned up a few other things, it builds and runs just fine.
rday
Very strange occurrence with meta-snap[py] x86 image … it works fine with starting it up under QEMU, then installing “hello-world” and running it, but I then installed “snapcraft” to see if there were any issues trying to build a snap, and just running “snapcraft --help” took 20-25 seconds before it responded with the standard help. And that’s constant, it’s not like the first invocation took long and subsequent ones were much faster.
Any idea what might be going on here? That’s a surprisingly long time just for a command to print out some help info. By the way, “snap --help” comes back quickly, so it’s something about “snapcraft”.
open top in a different terminal (ssh into qemu), that will likely help you know if something is eating the CPU.
807 252 root R 49152 21% 24% /snap/snapcraft/7010/bin/python /snap/snapcraft/7010/bin/snapcraft --help
I ran “snapcraft --help” in the background and fired up “top”, which showed me %VSZ of 21% and %CPU of 24%. Perhaps it’s Python that is dragging things to its knees.
Looks like meta-snapd it is. I’ ping the right folks to create a repo on github.
One question and something that’s not clear: Will PRs to that repository require signing Canonical’s CLA. Since I will be contributing on behalf of my employer, I need to know. I hope we can skip the CLA for this project
When it shows up, I’ll do another test to make sure it’s sane and works as expected. Is there anything else I should be doing here to help out?
Thanks to @mvo https://github.com/snapcore/meta-snapd is now up. I’ll import the meta-snappy there and fix the most obvious issues (like referencing the old url/name), and then I’ll add @om26er and @rpjday as contributors and we can start opening PRs
Cool. I’ll do a sanity test this weekend once the content is there.
I don’t see the layer at GitHub, has it been moved there?
rday
Sorry, I’ve been of for the last couple of days. Now I’m back, but there’s some high priority work related to factory reset, so meta-snapd is lower in the queue.
Fair enough, just let me know when there’s something I should look over.
rday
