The core snap's loader is tied to its libc. usr/bin/awk inside the core
snap refers to /lib64/ld-linux-x86-64.so.2, which is therefore incorrect
when called from a classic snap.
Add a wrapper for awk which calls awk in the core snap correctly,
through its own loader.
Separately, we also need to set LD_LIBRARY_PATH so that the loader can
find the shared libraries supplied by the core snap that satisfy its own
dependencies, rather than look at the host system or into our own snap
which may not have them. This was the original bug. Fixing this revealed
the problem above. Both issues are resolved by wrapping this call.
This does raise some questions such as what it means for a classic snap
to be making use of a core snap's binaries, and whether this is an
appropriate thing to do given that the core snap's binaries all specify
the "wrong" loader path in the classic case since the core snap won't be
mounted at the root of the filesystem. This might need some refactoring
of how the git-ubuntu snap works in the future, but for now we can fix
the awk case to fix the current regression in master.
The launchpadlib part requires "keyring" with no version restriction. By
requiring a particular version here, we're relying that some newest
version of keyring will work with this particular keyrings.alt, which
fails with keyring 15.0.0 vs. keyrings.alt 2.3. Since launchpadlib
already has no version restriction, do the same for keyrings.alt. Then
at least if "pip3 install" works, so should the snap.
Alternatively we could have added a version restriction to the
launchpadlib part, but at the moment that pattern isn't used anywhere,
and the requirements are taken from launchpadlib's setup.py with no
patching. If we want to restrict versions some other way, then we'll
need a major reworking of how the snap is put together.
Now the test checking that keyring can find a functional backend should
always pass.
If raw_repo.status() returns entries that are GIT_STATUS_IGNORED then
they don't represent the tree being dirty, so ignore this case. This
fixes a case where "git ubuntu tag" refuses to work even when a working
tree is clean.
This is same user as launchpad.
The path under the user's home (~/build) is left the same.
On launchpad the path is something like build-PACKAGEBUILD-XXXXXXX
but that seems less useful than a constant path for a user
using '--keep'.
