Pushing syncthing_1.4.0-rc.6_amd64.snap
After pushing, an attempt will be made to release to 'candidate'
Preparing to push '/var/tmp/tmp.ftQB4znTIX/syncthing_1.4.0-rc.6_amd64.snap' to the store.
Found cached source snap /home/release/.cache/snapcraft/projects/syncthing/snap_hashes/amd64/1a641f435e1f3d01f002a2abaa8af233052f3e6ad0dc93dc518a9a4d682ab10669fab9f0c62d7e8b72b5452f4f25c76c.
Generating xdelta3 delta for syncthing_1.4.0-rc.6_amd64.snap.
Pushing delta /var/tmp/tmp.ftQB4znTIX/syncthing_1.4.0-rc.6_amd64.snap.xdelta3.
Pushing syncthing_1.4.0-rc.6_amd64.snap.xdelta3 [===========================================================================] 100%
Processing...|
Error while processing...
The store was unable to accept this snap.
- found errors in file output: unable to read or access files in 'squashfs-root' due to mode 'rwxrwxrwt'
Apparently the root of the package / squashfs has mode 777. I couldn't immediately figure out why.
I think you recently contemplated removing snap support by the syncthing project. and if i remember correctly we have some more open, unaddressed snap bugs. given no contributors seem interested in snap, I'd really consider removing it (or maybe announce the intention to do so unless someone steps up to take care of it, though i don't know about the reach of such an announcement).
Yeah. Uptake is marginal, I鈥檝e just retained it because the cost to do so has been about zero as well. I don鈥檛 know what caused this breakage now, or if it鈥檚 always been this way and just the check is new. I did some experiments to build the snap in a docker (to simplify our build setup), but reverting that didn鈥檛 help today.
Fixed by chmodding the source dir prior to build inside the container... Snap survives to another day.
Most helpful comment
Fixed by chmodding the source dir prior to build inside the container... Snap survives to another day.