base: core20 snap builds are dispatched for i386, which always fails

Bug #1862258 reported by Ian Johnson on 2020-02-06
24
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Launchpad itself
High
Unassigned

Bug Description

When building snaps on LP, (and also through build.snapcraft.io where I first discovered this), there is not an obvious error that happens when one tries to build a snap with base: core20 on architecture i386. I think that LP should more clearly complain when this happens, currently I see this kind of error:

```
linux32: failed to execute snap: No such file or directory
Install failed
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 259, in run
    self.install()
  File "/usr/lib/python2.7/dist-packages/lpbuildd/target/build_snap.py", line 163, in install
    snap_name])
  File "/usr/lib/python2.7/dist-packages/lpbuildd/target/lxd.py", line 536, in run
    subprocess.check_call(cmd, **kwargs)
  File "/usr/lib/python2.7/subprocess.py", line 541, in check_call
    raise CalledProcessError(retcode, cmd)
CalledProcessError: Command '['lxc', 'exec', 'lp-focal-i386', '--', 'linux32', 'snap', 'install', '--channel=stable', 'core20']' returned non-zero exit status 127
```

I assume this specific error happens because lp-focal-i386 exists and is otherwise a fine image but has a broken snapd/core20 snap or doesn't have snapd/core20 snap at all on it?

See also https://bugs.launchpad.net/snapcraft/+bug/1862256 for the snapcraft side of this problem.

tags: added: lp-snappy
Changed in launchpad:
importance: Undecided → High
status: New → Triaged
Colin Watson (cjwatson) wrote :

While there may be more to do at the snapcraft build service level, my view on what we should do for this in Launchpad is as follows:

 * Extend `SnapBase` model so that we can specify which architectures are supported by Launchpad for a given base, probably by creating a new `SnapBaseArch` table and some helper properties on `SnapBase` to link things together (compare `ArchiveArch` and `Archive.processors`).
 * Extend either `Snap.requestBuildsFromJob` or `lp.snappy.adapters.buildarch.determine_architectures_to_build` to intersect the set of architectures supported by the base. (We already intersect explicit configuration in the snap recipe with any architecture configuration in snapcraft.yaml; the latter is preferred nowadays, but didn't exist when we first implemented snap building in Launchpad.)
 * Possibly change `Snap.requestBuild` to explicitly reject attempts to build a snap for an incompatible base/architecture combination.

If we do this, the common case will just work: we won't dispatch i386 builds for core20, since attempting to do so won't work. New architectures will also work naturally in a similar way.

It's possible that we may also want to explicitly flag that snapcraft.yaml requested architectures that aren't supported with the given base. My preference would be for this to be indicated somewhere where the user is more likely to see it, perhaps by `snapcraft` itself, but I'm open to doing it in Launchpad as well if we think that would be helpful. If we do this, then I think it should be in a "soft" way: that is, we should still dispatch builds for architectures that make sense, but we should indicate it in the list of recent builds. This may tie in to @twom's recent work on improving the presentation of build sets.

summary: - LP should complain loudly and clearly when asked to build a base: core20
- on i386
+ base: core20 snap builds are dispatched for i386, which always fails
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.