I don’t know where the “dirty” comes from there. I did at one point use a locally built snapd, but afterwards reverted to running it from the archives. The checksum seems to confirm I’m not using the old snapd from my $GOPATH.
Can you please reinstall the deb package and check if the version changes? Check if you have something weird set in your environment (like SNAP_REEXEC=0).
$ env | grep SNAP
$ sudo apt install --reinstall snapd
[sudo] password for cris:
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 90 not upgraded.
Need to get 9.706 kB of archives.
After this operation, 0 B of additional disk space will be used.
Get:1 http://de.archive.ubuntu.com/ubuntu xenial-updates/main amd64 snapd amd64 2.25 [9.706 kB]
Fetched 9.706 kB in 12s (786 kB/s)
(Reading database ... 304467 files and directories currently installed.)
Preparing to unpack .../archives/snapd_2.25_amd64.deb ...
Warning: Stopping snapd.service, but it can still be activated by:
snapd.socket
Unpacking snapd (2.25) over (2.25) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up snapd (2.25) ...
$ file /usr/lib/snapd/snapd
/usr/lib/snapd/snapd: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=f4b6cf3f5428dc8c7f4e80d803644db2038403a6, stripped
$ snap version
snap 2.15.2+git2550.g0ac9c21.dirty
snapd 2.26.14
series 16
ubuntu 16.04
$ sudo apt install --reinstall snap
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
snap
0 upgraded, 1 newly installed, 0 to remove and 90 not upgraded.
Need to get 372 kB of archives.
After this operation, 2.710 kB of additional disk space will be used.
Get:1 http://de.archive.ubuntu.com/ubuntu xenial-updates/universe amd64 snap amd64 2013-11-29-1ubuntu2.16.04.1 [372 kB]
Fetched 372 kB in 1s (321 kB/s)
Selecting previously unselected package snap.
(Reading database ... 304467 files and directories currently installed.)
Preparing to unpack .../snap_2013-11-29-1ubuntu2.16.04.1_amd64.deb ...
Unpacking snap (2013-11-29-1ubuntu2.16.04.1) ...
Processing triggers for man-db (2.7.5-1) ...
Setting up snap (2013-11-29-1ubuntu2.16.04.1) ...
$ snap version
snap 2.15.2+git2550.g0ac9c21.dirty
snapd 2.26.14
series 16
ubuntu 16.04
I seems that I’m still seeing the same problem. Commands below.
$ snap remove handbrake-jz
handbrake-jz removed
$ snap remove gnome-3-24
gnome-3-24 removed
$ snap install handbrake-jz
handbrake-jz 1.0.7-1 from 'jz' installed
$ handbrake-jz.ghb
You need to connect this snap to the gnome platform snap.
You can do this with those commands:
snap install --edge gnome-3-24
snap connect handbrake-jz:gnome-3-24-platform gnome-3-24:gnome-3-24-platform
(the '3-24' number defines the platform version and might change)
$ snap install --edge gnome-3-24
gnome-3-24 (edge) 3.24 from 'canonical' installed
$ snap connect handbrake-jz:gnome-3-24-platform gnome-3-24:gnome-3-24-platform
$ handbrake-jz.ghb
You need to connect this snap to the gnome platform snap.
You can do this with those commands:
snap install --edge gnome-3-24
snap connect handbrake-jz:gnome-3-24-platform gnome-3-24:gnome-3-24-platform
(the '3-24' number defines the platform version and might change)
@kalikiana That message is being emitted by the snap itself, so it’s hard to tell from our end what it’s really complaining about. It’s probably misjudging an issue it is finding and thinking that the interface isn’t connected.
Yes, that’s my snap. I don’t know if there is anything I can do from the package side to get it autoconnected, AFAIK at the moment it has to be done manually. It’s very irritating, I know
the message about gnome-platform is from the desktop-helper script from gnome-platform[1] which checks whether ${SNAP}/gnome-platform has been mounted, i.e. isn’t the empty folder that ships in the consumer snap.
@jzimm The issue above is that after being connected it’s still complaining. What sort of logic is it using to detect when it is connected or not? Can you debug this a bit with @kalikiana?
Thanks in advance…
Update: If that’s the desktop-helper script and before your application is called, we’ll get the person maintaining the script to figure this out. Sorry for the trouble there.
The issue isn’t in the desktop-launcher. This one just ls <mount-point> on start to check if the platform snap is connected or not. I’ve reported that particular issue via multiple channels upstream, but I can’t find the bug anymore, so maybe it has been wrongly closed?
This can be easily reproduced by the snapd team, so that you can debug it:
$ snap install gnome-3-24
$ snap install gnome-calculator
$ snap run gnome-calculator
You need to connect this snap to the gnome platform snap.
You can do this with those commands:
snap install --edge gnome-3-24
snap connect gnome-calculator:gnome-3-24-platform gnome-3-24:gnome-3-24-platform
(the '3-24' number defines the platform version and might change)
$ snap connect gnome-calculator:gnome-3-24-platform gnome-3-24:gnome-3-24-platform
$ snap run gnome-calculator
You need to connect this snap to the gnome platform snap.
You can do this with those commands:
snap install --edge gnome-3-24
snap connect gnome-calculator:gnome-3-24-platform gnome-3-24:gnome-3-24-platform
(the '3-24' number defines the platform version and might change)
$ snap run --shell gnome-calculator
ls $SNAP/gnome-platform/
-> as you can see the destination directory is still empty, despite the connection after first run. @niemeyer@zyga-snapd, do you need any other information from us to get this fixed?
Jamie added it as a “priority to the Snappy Team’s roadmap” in january
and it was raised as a problem several time on the mailing list without
a reply. The bug also didn’t get any activity until this week where Zyga
closed it without apparently even testing if the issue was resolved…
Anyway, yes, would be nice if the snappy team could finally look at that
issue, it has been an ongoing problem for us for a while
@seb128 The snapd team has been looking at that issue for good part of the last year, and you can search here in the forum for snap-update-ns and enjoy quite a bit of information around it. Also, in the bug you refer to you’ll see @zyga-snapd responding a few days ago saying:
Zygmunt Krynicki (zyga) wrote on 2017-08-07: #10
This should be fixed now. Can you please try with snapd 2.26.14 (just use stable channel) and report back if it is a problem for you?
So let’s please calm down and try to have a more productive and friendly conversation.
