cannot build snapd snap with build-base: core w/o base: core

Bug #1857019 reported by Ian Johnson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Snapcraft
Fix Released
Critical
Chris Patterson

Bug Description

When using just `build-base: core` in the snapd snap, snapcraft fails thusly:

```
Priming fontconfig-bionic
join() argument must be str or bytes, not 'NoneType'
We would appreciate it if you anonymously reported this issue.
No other data than the traceback and the version of snapcraft in use will be sent.
Would you like to send this error data? (Yes/No/Always/View) [no]: view
Traceback (most recent call last):
  File "/snap/snapcraft/3834/bin/snapcraft", line 11, in <module>
    load_entry_point('snapcraft==3.9.1', 'console_scripts', 'snapcraft')()
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/click/core.py", line 764, in __call__
    return self.main(*args, **kwargs)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/click/core.py", line 717, in main
    rv = self.invoke(ctx)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/click/core.py", line 1137, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/cli/_command.py", line 88, in invoke
    return super().invoke(ctx)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/click/core.py", line 956, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/click/core.py", line 555, in invoke
    return callback(*args, **kwargs)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/cli/lifecycle.py", line 288, in snap
    _execute(steps.PRIME, parts=[], pack_project=True, output=output, **kwargs)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/cli/lifecycle.py", line 79, in _execute
    lifecycle.execute(step, project_config, parts)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/lifecycle/_runner.py", line 122, in execute
    executor.run(step, part_names)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/lifecycle/_runner.py", line 176, in run
    self._handle_step(part_names, part, step, current_step, cli_config)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/lifecycle/_runner.py", line 190, in _handle_step
    getattr(self, "_run_{}".format(current_step.name))(part)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/lifecycle/_runner.py", line 265, in _run_prime
    self._run_step(step=steps.PRIME, part=part, progress="Priming")
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/lifecycle/_runner.py", line 309, in _run_step
    getattr(part, step.name)()
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/__init__.py", line 798, in prime
    self._do_runner_step(steps.PRIME)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/__init__.py", line 245, in _do_runner_step
    return getattr(self._runner, "{}".format(step.name))()
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/_runner.py", line 91, in prime
    "override-prime", self._override_prime_scriptlet, self._primedir
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/_runner.py", line 137, in _run_scriptlet
    scriptlet_name, function_call.strip()
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/_runner.py", line 193, in _handle_builtin_function
    function(**function_args)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/__init__.py", line 819, in _do_prime
    dependency_paths = self._handle_elf(snap_files)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/pluginhandler/__init__.py", line 831, in _handle_elf
    core_path = common.get_installed_snap_path(self._base)
  File "/snap/snapcraft/3834/lib/python3.6/site-packages/snapcraft/internal/common.py", line 92, in get_installed_snap_path
    return os.path.join(os.path.sep, "snap", snap_name, "current")
  File "/snap/snapcraft/3834/usr/lib/python3.6/posixpath.py", line 94, in join
    genericpath._check_arg_types('join', a, *p)
  File "/snap/snapcraft/3834/usr/lib/python3.6/genericpath.py", line 149, in _check_arg_types
    (funcname, s.__class__.__name__)) from None
TypeError: join() argument must be str or bytes, not 'NoneType'
```

I believe this is because the _handle_elf function assumes that there will always be a snap specified by `base: ...` when in this case there is not, there is only build-base.

Chris Patterson (cjp256)
Changed in snapcraft:
status: New → Confirmed
Revision history for this message
Ian Johnson (anonymouse67) wrote :

FWIW, this is probably a low priority bug since as per pedronis, the correct snapcraft.yaml for the snapd snap is (appreviated):

```
type: snapd
build-base: core
```

however we're not yet to the point where the store supports `type: snapd` for the snapd snap yet, so while it would be useful to be able to specify `build-base: core` without `type: snapd` in the meantime, building with both `type: snapd` and `build-base: core` is a "workaround" for this bug (even if we really can't do that since the store is confused).

Revision history for this message
Chris Patterson (cjp256) wrote :

base may in fact be None.

(1) it probably shouldn't attempt to search for dependencies in the base.

(2) And _get_linker_version_for_base() should probably be updated to use get_build_base() if base is None. But with it being implemented in ProjectOptions instead of Project, we don't quite have that readily available...

I'll discuss with sergiusens and see what he thinks.

Chris Patterson (cjp256)
Changed in snapcraft:
assignee: nobody → Chris Patterson (cjp256)
Chris Patterson (cjp256)
Changed in snapcraft:
status: Confirmed → In Progress
Revision history for this message
Michael Vogt (mvo) wrote :

I set this to critical as it blocks xnox from UC20 work right now. And because this is top priority right now this seems appropriate.

Changed in snapcraft:
importance: Undecided → Critical
Revision history for this message
Michael Vogt (mvo) wrote :

Fwiw, the acceptance criteria for us is that we can build snapd using https://github.com/snapcore/snapd/pull/7904

Revision history for this message
Sergio Schvezov (sergiusens) wrote :

Ok, from Low to Critical, we will give this priority.

Revision history for this message
Sergio Schvezov (sergiusens) wrote :

This should be a bug only for type app and is correlated to the use of libc6
Have you set "type: snapd"?

Revision history for this message
Sergio Schvezov (sergiusens) wrote :

Sorry, it is late, but in new snapcraft you cannot use "type: app" without specifying a base, we are missing a guard to dissallow that scenario.

Revision history for this message
Chris Patterson (cjp256) wrote :

I confirmed that I can build snapd using snapcraft from the `edge` channel, with the following diff applied to Ian's PR:

diff --git a/build-aux/snap/snapcraft.yaml b/build-aux/snap/snapcraft.yaml
index dfde086354..de03de4135 100644
--- a/build-aux/snap/snapcraft.yaml
+++ b/build-aux/snap/snapcraft.yaml
@@ -1,6 +1,6 @@
 name: snapd
 # TODO: enable this when the store is ready
-# type: snapd
+type: snapd
 summary: Daemon and tooling that enable snap packages
 description: |
   Install, configure, refresh and remove snap packages. Snaps are
@@ -12,7 +12,7 @@ description: |
 adopt-info: snapd
 # the base is only needed here for snapcraft to check the ELF sections of
 # binaries inside the snap, which is an unnecessary check for snapcraft itself
-base: core
+build-base: core
 grade: stable
 license: GPL-3.0

We still need to follow up with a PR to ensure the invalid schema configuration is caught.

Revision history for this message
Ian Johnson (anonymouse67) wrote :

Unfortunately we cannot yet set `type: snapd` because the store is not ready for snaps to change the type yet. Are you saying that snapcraft will not fix this bug unless we set `type: snapd` on the snap?

Additionally we cannot set a base for the snapd snap because it doesn't make sense for that. I don't remember all of the reasons but I can ask Samuele to comment on this specifically tomorrow.

Revision history for this message
Chris Patterson (cjp256) wrote :

Ian,

> Unfortunately we cannot yet set `type: snapd` because the store is not ready for snaps to change
> the type yet. Are you saying that snapcraft will not fix this bug unless we set `type: snapd` on > the snap?

If it comes to it, yes, I'm sure we can probably put in a workaround for the store issue. When I talked to Sergio about it, I now understand it to be an invalid scenario (see below).

> Additionally we cannot set a base for the snapd snap because it doesn't make sense for that.
> I don't remember all of the reasons but I can ask Samuele to comment on this specifically tomorrow.

Sorry if I confused things. You should _not_ set "base", just "build-base". The issue at hand is that snapcraft is supposed to require that "type: app" is paired with a valid "base". In the case of snapd, there is no "base". Hence the dilemma. The fact you got it as far as you did was due to a bug in snapcraft's schema which should have rejected the config that led to this.

I suppose a temporary workaround for the store issue could be to have snapcraft trigger the behavior of "type: snapd" when "name: snapd"? Just a thought if the store fix is not just around the corner... :)

Revision history for this message
Sergio Schvezov (sergiusens) wrote :

What is preventing the Snap Store from just doing the right thing?

Revision history for this message
Sergio Schvezov (sergiusens) wrote :

cjp256 the more elegant fix would be to not do elf checks at all if there is no base.

Changed in snapcraft:
status: In Progress → Fix Committed
Revision history for this message
Sergio Schvezov (sergiusens) wrote :

Part of 3.10

Changed in snapcraft:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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