32 bit build failures with Launchpad / missing snap

Good evening all. I am attempting to troubleshoot an issue with our snap builds in Launchpad. Is there an additional step required when publishing 32bit? For example - when pushing the snap to the store, I had just pushed my local build.

When reviewing the error (see below)

p, li { white-space: pre-wrap; }
 : Configuring file /etc/resolv.conf
+ cd /var/lib/snapd/seed
+ SNAPPY_STORE_NO_CDN=1 snap download core
2018/03/01 15:16:04.084684 cmd.go:156: cannot read /proc/self/exe: readlink /proc/self/exe: no such file or directory
Fetching snap "core"
Fetching assertions for "core"
Install the snap with:
   snap ack core_4108.assert
   snap install core_4108.snap
+ cd /var/lib/snapd/seed
+ SNAPPY_STORE_NO_CDN=1 snap download ubuntu-budgie-welcome
2018/03/01 15:16:37.657982 cmd.go:156: cannot read /proc/self/exe: readlink /proc/self/exe: no such file or directory
Fetching snap "ubuntu-budgie-welcome"
error: cannot find snap "ubuntu-budgie-welcome": snap not found
P: Begin unmounting filesystems...

For clarity - this is happening during our 32bit ISO build. Testing on a 32bit VM - the package is not found (tested by another team member). This makes me think I must have fudged something, or missed a detail when pushing to the store. For clarity - when configuring the build (snapcraft) - 32 bit was selected.


I then looked in LP at the buildlogs. All is reported as successful there.

Snapped ubuntu-budgie-welcome_0.6.1_i386.snap
Revoking proxy token...
RUN: /usr/share/launchpad-buildd/slavebin/in-target scan-for-processes --backend=lxd --series=xenial --arch=i386 SNAPBUILD-159049
Scanning for processes to kill in build SNAPBUILD-159049
RUN: /usr/share/launchpad-buildd/slavebin/in-target umount-chroot --backend=lxd --series=xenial --arch=i386 SNAPBUILD-159049
Stopping target for build SNAPBUILD-159049
RUN: /usr/share/launchpad-buildd/slavebin/in-target remove-build --backend=lxd --series=xenial --arch=i386 SNAPBUILD-159049

I’m currently downloading a 32bit ISO to test on my own.

Current thought. Maybe my issue is that the build system dropped both arch into the edge channel, but is there another command to promote to stable for multiple architectures? I am sure I am missing a small detail that is here.


What happens if you run snapcraft status ubuntu-budgie-welcome from an account that can administer that package? That should give you a breakdown of the architectures supported by its releases.

Well it looks like we have an i386 build available.

Track    Arch    Channel    Version    Revision
latest   amd64   stable     0.6.1      11
                 candidate  0.6.1      8
                 beta       0.6.1      13
                 edge       0.6.1      15
         i386    stable     0.6.1      12
                 candidate  ^          ^
                 beta       0.6.1      14
                 edge       0.6.1      16

First thought was that maybe We seeded something incorrectly, but the x64 built without issue.

The other odd thing is that when one of my team produced a build he noted:

4:14 AM also noted that building locally on 17.10 produces a snap size of approx 90Mb - which is much smaller than the xenial snap produced by launchpad. odd

I see it from a 32-bit LXC container as well:

$ snap info ubuntu-budgie-welcome
name:      ubuntu-budgie-welcome
summary:   Welcome screen application to greet new users on their first login.
publisher: ubuntubudgie
description: |
  The ubuntu-budgie-welcome application was designed to greet a new user at the
  first run after installing Ubuntu Budgie. This app will show you around
  the official Ubuntu flavour, make a few recommendations, showcase some
  of the available budgie applets (to personalize your desktop), and ease the
  installation effort around a few common applications.
snap-id:     48MOAkHBkwgODhqYbDGS3ry7VxTIfBRo
  stable:    0.6.1 (12) 126MB classic
  candidate: ↑                
  beta:      0.6.1 (14) 126MB classic
  edge:      0.6.1 (16) 129MB classic
1 Like

It’s possible the store had a hiccup or something. I’m not really sure what to say now-- things look okay. Can your 32-bit team member try again and see if things are working now? Or yeah, if you’re downloading a 32-bit ISO you can. Things look good from my perspective anyway.

Thank you very much for looking at this. I’ll check out the results when the next daily ISO spins (if it has not yet happened).

Side note - never realised you could spin up a 32bit container on a 64-bit host!

Man, you’re missing out!

$ lxc launch ubuntu:xenial/i386
1 Like

Yeah, I ran to the docs right after this! Haha.

The solution was to release the 32bit via the dashboard. I have some additional questions but will put into an appropriate thread as it runs along release mgmt vs this 32bit issue.