@jdstrand any more updates on this?
I know this keeps get pushed back but it is literally at the top of the queue now and I hope to start work on it this week.
This feature also requires changes to the review-tools to expand the checks for base snaps. I did that a little while ago and this is in production in the store.
I’ve just now submitted https://github.com/snapcore/snapd/pull/8496 which, when it lands, will (finally) allow freedesktop-sdk-runtime to be usable by other snaps in the store.
cc @kenvandine
3 Likes
FYI, this was just now merged and will be in 2.45. The changes should be in tonight’s edge snap. Please test freedesktop-sdk-runtime-19-08 with core/snapd from edge and let us know if you have any issues.
2 Likes
@jdstrand, I have just tested quickly and the new apparmor profile with edge snapd seems to fix our issues.
Through I will have to do some cleanup and little fixes before I submit it to the store. But now the ball is on my side.
Thank you!
FYI, all the prerequisites are in snapd 2.45 now and I updated Process for reviewing base snaps with some additional details so this request can move forward whenever you’ve confirmed that your snap is ready.
I have reuploaded a newer version. It is freedesktop-sdk-runtime-2008. I also uploaded freedesktop-sdk-sdk-2008. This is the full SDK which is needed for development applications (e.g. GNOME Builder). Those are beta uploads (they are in edge track). We are going to have the first release of 20.08 in few weeks.
- Base snaps shall not use tracks"
Does that mean I can only upload stable?
And I will upload other architectures when x86_64 has been vetted.
I missed this question when it appeared. No, you can upload to latest/edge latest/beta etc.
But snapd will always only auto install the base from latest/stable. For testing you can pre-install the base alone with snap install --channel and then install snaps that require it for testing. They will use the base as installed from the risk you chose.
Yikes, sorry for the delay on this! Since this is our first community base snap of this nature, I’m going to follow Process for reviewing base snaps rigorously so other @reviewers can more easily participate.
The snap’s name is freedesktop-sdk-runtime-2008 which is compliant with the ABI naming convention we are looking for. The snap does not currently use assumes: [ snapd2.45 ].
- @valentind - can you update the snap to use assumes?
@valentind - there is a strong preference for base snaps to be maintained by a community or project. You are currently listed as the publisher with no collaborators. Would it make sense to create a ‘Freedesktop.org’ username, adding yourself and others as collaborators? If you are amenable to this, perhaps @popey or @roadmr can assist with the process?
The base contains all the necessary empty directories for snap-confine (this is verified by the review-tools).
All the files in the base are root/root with no unusual permissions (this is verified by the review-tools).
I used unsquashfs -lls /path/to/snap |grep -E 'squashfs-root/(dev|etc|home|lib/modules|lib/firmware|mnt|media|run|proc|root|snap|var/snap|sys|usr/lib/firmware|usr/lib/modules|usr/lib/snapd|usr/src|var/lib/dhcp|var/lib/extrausers|var/lib/jenkins|var/lib/snapd|var/log|var/tmp)' and found the following:
- there are files in squashfs-root/etc
- there are files in squashfs-root/proc
@valentind - can you use stage in your snapcraft.yaml or otherwise remove the files in these directories (but not the directories themselves)?
I then noticed it is shipping:
- squashfs-root/app
- squashfs-root/snap
These are not going to be available to the snap at runtime because the default base template policy does not allow them.
@valentind - can you remove these?
@valentind - can you comment on each of these:
- Will you not request using tracks for this snap?
- Do you commit to not intentionally break consumers of this snap? (Eg, by removing files, changing ABIs, etc)
- Do you commit to be responsive to bugs and regressions caused by updates to the snap?
Assuming the that @valentind answers in the affirmative to these questions, cleans up the snap in the requested ways and ideally creates a community/project username with collaborators, I think this snap can undergo publisher vetting.
3 Likes
@valentind - as an aside, the snap is shipping quite a lot, which is fine, but I want to mention that once approved and you’re on your way, future uploads will be automatically checked to verify if files are dropped from the snap or ABIs are dropped and if that happens, the revision will fail review. For the smoothest experience going forward, I highly suggest that you prune the snap to just what you want. It is fine if you choose to only make the minimal changes I requested, but I wanted you to know how the process works for base snaps.
Thanks for your work on this!
1 Like
Just want to step in and say: keep going, @valentind ! I know it’s been more than a year since this process started, but it’ll be very beneficial for the community. Looking forward to this!
Thanks also to Snap team, for directing Valentin through this.
1 Like
@valentind thanks a lot for you patience. Any chance you could review suggestions and questions made by @jdstrand?
Sorry, I was busy. I will go through the review and fix the issues. I will be back with a revised version.
We check ABI is stable (both forward and backward, no symbol added nor removed). However I cannot for sure know if files are removed. We only verify that libraries are not removed (and also not added). But for other type of files, they could be added. Could I have detailed on what the check is so I can add more rules within the Freedesktop SDK to be compatible with it?
Glad to hear about your ABI checks. That’s awesome and perfect for a base snap publisher! 
Adding files is not a problem (even libraries, but as the publisher you can of course be more strict), but removing is. Note that removing files doesn’t mean the revision can’t be manually approved; a reviewer then needs to examine the situation and reach out to discuss if it is ok.
There are two paths here: either remove the files you don’t expect people to use so there are fewer chances of dropping things going forward (where my suggestions were coming from) or not generally worry about it with the understanding that you might occasionally have a review hiccup that requires manual review.
Removing /snap makes the application not run with an error message related to bind mounting /snap. So I think I need to have it.
For /app this was to allow application to bind mount there. This is to allow conversion of Flatpak applications to Snap, since in Flatpak, the application expects to be installed in /app.
However latest version of snapd does not allow to bind mount in /app anymore. The following check has been added:
switch elems[1] {
// this list was produced by taking all of the top level
// directories in the core snap and removing the explicitly
// denied top-level directories
case "bin", "etc", "lib", "lib64", "meta", "mnt", "opt", "root", "sbin", "snap", "srv", "usr", "var", "writable":
default:
return fmt.Errorf("layout %q defines a new top-level directory %q", layout.Path, "/"+elems[1])
}
It seems to me wrong that applications are allowed only directories from core runtime when they do not use that. Instead, Snapd should check the list of top level directories in used runtime and remove forbidden directories.
I can work-around that by mounting thing ins /var/app and adding a symlink /app -> var/app.
For the tracks, this is a question I had before. For the Flatpak world, before release we usually release betas for people to test so that we can fix before proper release. Because once we have released we cannot change much, for example we cannot break ABI. The way we do it for Flatpak is that we have a secondary repository so that only application developers and testers can test it.
It would have been nice for Snap to also have something similar. Note that once we get out of beta, we do not release new betas. Only updates to stable. Also note that every release of the Freedesktop SDK (which happen yearly) will have its own runtime on snap. So new features come only yearly an in different runtime. However it would have been nice if that runtime could be published first as beta.
For the second question. No, we will not break anything. Updates will mostly be bug fixes. That is we update software with their minor bug fixes releases, and eventually we back port fixes for software that do not provide those. We have the same requirements for Flatpak. An application that was built with a SDK of a certain release will work with any updated runtime for the same release branch.
I am not sure what kind of commitment you require for responsiveness if newer snapd requires a change in our runtime. We are community driven. So it is hard to say that at any moment there will be someone that will quickly respond. But for sure there will always be maintainers that will accept contribution from community and help deploy them.
1 Like
I just approved r1 of freedesktop-sdk-runtime-2008 in the store and made a change to the review-tools so this will pass automated review with future uploads (ie, it is allowed to be a base snap). This is not yet in production so future uploads will require a manual approval until it is.
Before you promote to stable, I suggest considering pruning some of the files we discussed that make sense to you and your users. If you do, the next upload will not pass due to missing files, but this is straightforward to manually approve once you tell the missing files are ok to drop.
I noticed a freedesktop-sdk-sdk-2008 in the store and rejected it as it was unclear that it wasn’t a duplicate. Please advise if this is in error.
1 Like