Please enable riscv64 for the gnome-42-2204-sdk and gnome-42-2204 snaps

As it stands I don't think we can do this - these snaps clone a bunch of repositories from GitHub using upstream-controlled tags that could in principle change which commits they point to, and our riscv64 builders don't currently have any isolation between builds, which means that we have to be very paranoid about what we allow.

Would you rather do a bunch of work to pin everything very exactly, or wait until we have properly isolated riscv64 builders? The latter is waiting for https://bugs.launchpad.net/charm-nova-compute/+bug/2023211 to be fixed and backported to PS6.

I think we'll have to wait, thanks!

@Colin

If we would replace all snapcraft.yaml tag references by the git hashes of the tags, would that resolve you security concerns? Or would other changes be needed too like moving the repository from GitHub to Launchpad?

@Ken
Using hashes instead of tags seems to be preferable security-wise for any snap that we build irrespective of the Launchpad issue.

Best regards

Heinrich

@Ken

cjwatson informed me that riscv64 builders in LP are virtualized and unrestricted now.

Are you able to schedule riscv64 builds now or is still support from the Launchpad team needed?

Yes, this should just be a matter of going to "Change details" on your snap recipe and editing the list of processors now.

I've added riscv64 to the snap build but we're getting launchpad errors during build:

Failed to fetch package: The item '/root/.cache/snapcraft/download/libwayland-bin_1.20.0-1ubuntu0.1_riscv64.deb' could not be fetched: 501 Gateway error [IP: 10.10.10.1 8222]

https://launchpadlibrarian.net/700176992/buildlog_snap_ubuntu_jammy_riscv64_gnome-42-2204-sdk_BUILDING.txt.gz

Can you please retry the build? It may have been something transient, and if it isn't then that at least gives us more information.

Is this a repeated problem you're experiencing, or just a one-off?

We received again a network error on riscv64. The other architectures worked fine.

https://launchpad.net/~desktop-snappers/+snap/gnome-42-2204-sdk/+build/2313099/+files/buildlog_snap_ubuntu_jammy_riscv64_gnome-42-2204-sdk_BUILDING.txt.gz

This particular error received was an HTTP 407 which is an indication that the proxy authentication expired. Suspiciously, 6 hours later.

Has this build ever worked for riscv64? If so, how long did it take?

Current theory is that if it were possible to retrieve all dependencies up-front near the beginning of the build, then the HTTP 407 wouldn't be encountered.

Local snap builds work fine. There is no reason provided why the network connection should be disabled before the build ends.

Looking at the current build progress the total build time probably would not exceed 12h.

To be clear, are you saying that you have built this snap for riscv64 previously? How long did the build take?

The network connection is not disabled. The proxy token is only valid for 6 hours. This expiry is by design, as an additional control.

One could also argue the other side; there is no reason provided why a build should still be retrieving dependencies after 6 hours.

@Ken
When building the gtk4 part meson tries to resolve the graphene-gobject-1.0 dependency via git clone. Should we add libgraphene-1.0-dev as build-dependency? That package provides /usr/lib/x86_64-linux-gnu/pkgconfig/graphene-gobject-1.0.pc.

https://gitlab.gnome.org/GNOME/gtk.git contains tag 4.12.3 has a file subprojects/graphene.wrap which define from which source to build graphene if graphene-gobject-1.0.pc is not found.

We are staging package libgraphene-1.0-dev in the snap. It seems unreasonable to let the gtk4 build download one version of graphene and then deploy a different one.

Looking at the buildlog there seem to be other instances where we could provide packages instead of letting meson build subprojects, e.g. pango needs gi-docgen, libpsl needs libsysprof-capture-4-dev.

The version of libgraphene-1.0-dev in jammy would be good enough to build gtk4, but I suspect there will be others that aren't new enough in jammy and will need the submodule.

My local builds have been some months ago. I will respin a local build. But as Launchpad is much slower than real hardware this only provides a lower bound for the run time.

The gnome-sdk snap build process has multiple parts. Apt packages defined as build dependencies are downloaded at the beginning of the snapcraft build process. But the meson build process of the individual parts will download additional sources of sub-projects. This cannot be done before the building of the respective part starts.

A prior build of the gnome-42-2204 snap on a SiFive HiFive Unmatched board used 08h34. On Launchpad I would expect at least double this time.