Yeah, I’ve run a few snaps under lxd but having real trouble with multipass. Not sure if that’s a local issue for me, my system or what. Need to investigate further.
This lot built successfully with 3.9.1 in candidate. I installed a few and they worked fine.
✓ - dosbox-jz-snap (use-lxd) ✓ - irssi (lxd) ✓ - links (lxd) ✓ - mutt (use-lxd) ✓ - ddgr (lxd) ✓ - googler (lxd) ✓ - helm (use-lxd) ✓ - axel (use-lxd) ✓ - brackets (use-lxd) ✓ - brave (lxd) ✓ - corsixth (use-lxd) ✓ - cumulonimbus (lxd) ✓ - discord (lxd) ✓ - discord-ptb (lxd) ✓ - dosbox-x (use-lxd) ✓ - duckmarines (lxd) ✓ - eclipse (use-lxd) ✓ - fkill (lxd) ✓ - get-iplayer (lxd) ✓ - ghost-desktop (use-lxd) ✓ - gitter-desktop (use-lxd) ✓ - inadyn (lxd) ✓ - irccloud-desktop (use-lxd) ✓ - jenkins (use-lxd) ✓ - magic-wormhole (use-lxd) ✓ - mattermost-desktop (use-lxd) ✓ - mdl (use-lxd) ✓ - minetest (use-lxd) ✓ - mrrescue (lxd) ✓ - mumble (use-lxd) ✓ - offlineimap (use-lxd) ✓ - opentoonz (use-lxd) ✓ - opentoonz-morevna (use-lxd) ✓ - atom (lxd) ✓ - opentyrian (lxd) ✓ - pyradio (use-lxd) ✓ - scummvm (lxd) ✓ - sdlpop (use-lxd) ✓ - sentry (lxd) ✓ - simplenote (use-lxd) ✓ - slack-term (lxd) ✓ - spelunky (lxd) ✓ - storjshare-gui (lxd) ✓ - sublime-text (lxd) ✓ - tcpie (use-lxd) ✓ - teleconsole (lxd) ✓ - term2048 (lxd) ✓ - tmnationsforever (lxd) ✓ - vagrant (use-lxd) ✓ - vscode (lxd)
I tested 3.9.1 with the following snaps:
- drawing (Uses gnome-3-32-1804 content snap, no extension)
- gnome-nibbles (uses gnome-3-28 snapcraft extension)
- gnome-characters (uses gnome-3-28-1804 content snap, no extension)
All built using multipass. All built successfully and run as expected.
Do any of these define a base and have you noticed the use, or lack thereof, of snapcraft generated wrappers being set for command entries?
For the ones I posted any that say (use-lxd) are using a base, those that say (lxd) are not. Is there any specific use case you want covered?
The question, to be more precise, was more in-line with asking if you ran the ones that you built that use bases to verify the fact that the lack of a wrapper in some cases did not break them.
3.9.2 is now on candidate fixing a couple of issues, most prominently, one relate to manifest generation when stage-packages were used with advanced grammar.
Snapcraft 3.9 (3.9.2) is now in the stable channel.
It seems as if
kde-frameworks-5-core18 is still not auto-connected. When I install
kcalc-merlijn --edge, for example, it doesn’t have the connection yet. Should this not be the case or am I doing something wrong?
I’d really like to use the
kde-neon extension for the Krita snap, but I can’t until this auto-connection is granted…
More info: Kde-neon autoconnect
This is correct, for auto-connection, the publisher should engage with the process for that to be the case. So far, kde snaps have been fully driven by KDE as a publisher on behalf of its developers.
The release has been rolled back temporarily, we found an issue with build environments and the use of the snapd snap when the base is set to core.
It has been addressed on https://github.com/snapcore/snapcraft/commit/1eebc27968e20e63ead11f7214c655284357fef2 … we should be back on track shortly.
3.9.3 with the mentioned fixed is on candidate, if not complaints are raised we will promote this on Monday
I’m guessing there’s still a blocking issue in 3.9.3?
We just put 3.9.4 into candidate, a round of verification from users of Snapcraft would be appreciated. Here is what changed:
We just put 3.9.5 into candidate, a round of verification from users of Snapcraft would be appreciated. Here is what changed:
3.9.5 is now on the stable channel
Docker images are not updated.
✗ podman run snapcore/snapcraft:stable snapcraft --version snapcraft, version '3.8'
Not yet, we need to make a core switch dance for the docker images, and from your other topic, you can infer why
Actually I could not.
Infer why they were not updated, not why they were not working.