Building snaps with kde-neon extension is not working
#37
Comments
|
Hi, thanks for the report!
The later, I think. Your usage seems correct but we probably need to do some work to support extensions (in particular those that need sdks). The usage of |
|
Thanks for replying and looking into it! As further information, I also tried building a Docker image based on the older Dockerfile for running Snapcraft in Docker. The below is the Dockerfile I made based on the above instructions: ARG RISK=stable
ARG UBUNTU=jammy
FROM ubuntu:$UBUNTU as builder
ARG RISK
ARG UBUNTU
RUN echo "Building snapcraft:$RISK in ubuntu:$UBUNTU"
# Grab dependencies
RUN apt-get update
RUN apt-get dist-upgrade --yes
RUN apt-get install --yes \
curl \
jq \
squashfs-tools
# Grab the core22 snap (which snapcraft uses as a base) from the stable channel
# and unpack it in the proper place.
RUN curl -L $(curl -H 'X-Ubuntu-Series: 16' 'https://api.snapcraft.io/api/v1/snaps/details/core22' | jq '.download_url' -r) --output core22.snap
RUN mkdir -p /snap/core22
RUN unsquashfs -d /snap/core22/current core22.snap
# Grab the snapcraft snap from the $RISK channel and unpack it in the proper
# place.
RUN curl -L $(curl -H 'X-Ubuntu-Series: 16' 'https://api.snapcraft.io/api/v1/snaps/details/snapcraft?channel='$RISK | jq '.download_url' -r) --output snapcraft.snap
RUN mkdir -p /snap/snapcraft
RUN unsquashfs -d /snap/snapcraft/current snapcraft.snap
# Fix Python3 installation: Make sure we use the interpreter from
# the snapcraft snap:
RUN unlink /snap/snapcraft/current/usr/bin/python3
RUN ln -s /snap/snapcraft/current/usr/bin/python3.* /snap/snapcraft/current/usr/bin/python3
RUN echo /snap/snapcraft/current/lib/python3.*/site-packages >> /snap/snapcraft/current/usr/lib/python3/dist-packages/site-packages.pth
# Create a snapcraft runner (TODO: move version detection to the core of
# snapcraft).
RUN mkdir -p /snap/bin
RUN echo "#!/bin/sh" > /snap/bin/snapcraft
RUN snap_version="$(awk '/^version:/{print $2}' /snap/snapcraft/current/meta/snap.yaml | tr -d \')" && echo "export SNAP_VERSION=\"$snap_version\"" >> /snap/bin/snapcraft
RUN echo 'exec "$SNAP/usr/bin/python3" "$SNAP/bin/snapcraft" "$@"' >> /snap/bin/snapcraft
RUN chmod +x /snap/bin/snapcraft
# Multi-stage build, only need the snaps from the builder. Copy them one at a
# time so they can be cached.
FROM ubuntu:$UBUNTU
COPY --from=builder /snap/core22 /snap/core22
COPY --from=builder /snap/snapcraft /snap/snapcraft
COPY --from=builder /snap/bin/snapcraft /snap/bin/snapcraft
# Generate locale and install dependencies.
RUN apt-get update && apt-get dist-upgrade --yes && apt-get install --yes snapd sudo locales && locale-gen en_US.UTF-8
# Set the proper environment.
ENV LANG="en_US.UTF-8"
ENV LANGUAGE="en_US:en"
ENV LC_ALL="en_US.UTF-8"
ENV PATH="/snap/bin:/snap/snapcraft/current/usr/bin:$PATH"
ENV SNAP="/snap/snapcraft/current"
ENV SNAP_NAME="snapcraft"
ENV SNAP_ARCH="amd64"
ENV SNAPCRAFT_BUILD_ENVIRONMENT="host"When I try to build the Snap package with the above image, I obtain the same error as with Snapcraft Rocks: The execution log is below: Hope this helps debug further and hope this eventually starts working in the newer Rocks images :) |
|
A-ha! I just noticed from the above log that the path Snapcraft is trying to use is: However, the extension is actually installed in here (notice no For the sake of testing I manually copied the contents from The example build then fails at the same place as in a regular Snapcraft installation in Ubuntu (as expected). I went to check in my testing Ubuntu VM and the extension is also in Will try to investigate more where is the actual problem. |
|
Looking more into this now. I now learned about the kde-neon/sdk:
source: /snap/snapcraft/11471/share/snapcraft/extensions/desktop/kde-neon
plugin: make
make-parameters:
- PLATFORM_PLUG=kf5-5-111-qt-5-15-11-core22In the (old) Docker-based Snapcraft it does not resolve correctly: kde-neon/sdk:
source: /snap/snapcraft/current/usr/share/snapcraft/extensions/desktop/kde-neon
plugin: make
make-parameters:
- PLATFORM_PLUG=kf5-5-111-qt-5-15-11-core22And in the Snapcraft Rocks image expands to this: In the Snapcraft Rocks image, the extensions seem to be installed in |
|
Alright, digging deeper, I think the issue is in how Snapcraft searches for extensions. When expanding extensions, the following function is used by the extensions in Snapcraft: As it can be seen, this is hard-coded to the Python interpreter's system prefix: return Path(sys.prefix) / "share" / "snapcraft" / "extensions"In the case of the old-Docker Snapcraft image, the Python interpreter is set as: RUN echo 'exec "$SNAP/usr/bin/python3" "$SNAP/bin/snapcraft" "$@"' >> /snap/bin/snapcraftWhich results in However, the Snapcraft own Snap metadata uses apps:
snapcraft:
environment:
# https://github.com/lxc/pylxd/pull/361
PYLXD_WARNINGS: "none"
command: bin/python $SNAP/bin/snapcraft
completer: snapcraft-completionIf I update the old-Dockerfile accordingly to match the above: RUN echo 'exec "$SNAP/bin/python" "$SNAP/bin/snapcraft" "$@"' >> /snap/bin/snapcraftThen it works correctly! 🎉 For the Snapcraft Rocks image, the Python interpreter used is installed in In summary, I'm convinced now that the Snapcraft Rocks image should have the Snapcraft data installed in EDIT: Sorry for all the spam 🙈. |
Hello, I recently found out about this repository and its intention to be the official way to build Snap packages in Docker.
I tried to build our Snap packages using
ghcr.io/canonical/snapcraft:8_core22but sadly it did not work as expected.The problem seems to be when using the
kde-neonextension.Consider the following
snap/snapcraft.yamlexample adapted from the official guide for Qt5/KF applications:The above Snapcraft file does not build using the
ghcr.io/canonical/snapcraft:8_core22image:The same Snapcraft file does start building correctly in Ubuntu with the regular
snapcraftcommand:Is there something I'm doing wrong when using the
ghcr.io/canonical/snapcraft:8_core22image or Snapcraft files using extensions is not yet supported by the images in this repository?The text was updated successfully, but these errors were encountered: