Is it possible to drop an unsupported architecture from the store?

[alan_g]

While experimenting with the build.snapcraft service I inadvertently built mir-test-tools for s390x which got pushed to latest/edge automatically. That build is unwanted, has incorrect content, and I have no capability for, nor interest in, supporting s390x for this snap.

I’m now getting reminders that this upload contains outdated libraries. Is there a way to remove the s390x architecture for https://snapcraft.io/mir-test-tools/ from the store?

[popey]

Note the revisions in each architecture/channel. Close the channel(s), then re-publish the non-s390x revisions to their channels, and don’t re-publish the s390x one.

[alan_g]

@popey

Note the revisions in each architecture/channel. Close the channel(s), then re-publish the non-s390x revisions to their channels, and don’t re-publish the s390x one.

I tried that and got it removed from the /releases management page. That’s progress thank!

Sadly, it is still there on the store page in the nested dropdown for “Show architecture”. (Maybe that just needs time to propagate?)

[popey]

^ @pheurton does the storefront cache architectures? Can that be flushed?

[alan_g]

@alan_g

Sadly, it is still there on the store page in the nested dropdown for “Show architecture”. (Maybe that just needs time to propagate?)

Followup: This still hasn’t changed.

[popey]

Perhaps a bug needs filing.

[alan_g]

@popey

Perhaps a bug needs filing.

Snap homepage shows unsupported architectures

[adasiko]

This seems to have been a caching issue. Everything seems to be in order now.

Same problem. When does a cache refresh happen?

[bmw]

I’m still seeing this problem too on https://snapcraft.io/certbot. I (temporarily) closed the edge channel, but the i386 architecture is still listed on the snap store page and testing on a i386 machine, the snap can still be installed.

[ogra]

closing channels only helps for already built snaps indeed … to prevent your snap from building on unwanted arches you need to use the architectures: option in snapcraft.yaml:

Architectures

By default, Snapcraft builds a snap to run on the same architecture as the build environment. This behaviour can be modified with an optional root architectures keyword which is added to a snap’s snapcraft.yaml. The architectures keyword defines a set of both build and run architectures with the following syntax: architectures: - build-on: [<build arch 1>, <build arch 2>] run-on: [<run arch 1>, <run arch 2>] valid values include s390x, ppc64el, arm64, armhf, amd64 and i386 the default…

i.e.:

architectures:
  - build-on: [ amd64, armhf ]

to build only on these two arches …

[bmw]

For what it’s worth, I’m still seeing this problem and the cause is not i386 snaps continuing to be built.

Since my previous message, we temporarily offered i386 snaps again, but stopped over a month ago. I closed and reopened the channel containing the i386 snap and the web UI for our snap looks like:

Despite that, you can still see a i386 snap listed at https://snapcraft.io/certbot and it is still installable on a i386 system.

[bmw]

I’m still having this problem. Is there any way to resolve this?

[alan_g]

Me too. This appears to be the bug: https://bugs.launchpad.net/snapstore-server/+bug/1842631

[lucyllewy]

@ogra

architectures:
  - build-on: [ amd64, armhf ]

I don’t think this is what you want. That will build on amd64 and set the runs-on to amd64 AND armhf for the same .snap file. It will, in parallel, build on armhf and set the runs-on for THAT snap file to the same amd64 and armhf. So from the two builds this will generate both snap files will be installable onto an incorrect architecture.

Instead, you likely want:

architectures:
  - build-on: amd64
  - build-on: armhf

With the version you suggested it is the equivalent to below, which I’m sure you’ll agree is not desirable:

# DO NOT USE THIS!
architectures:
  - build-on: amd64
    run-on: [amd64, armhf]
  - build-on: armhf
    run-on: [amd64, armhf]

## also equivalent to:
architectures:
  - build-on: [amd64, armhf]
    run-on: [amd64, armhf]

[ogra]

@lucyllewy

builds-on

while this is indeed correct, it should be build-on (no s) …

[lucyllewy]

oops. I coulda sworn they were statements rather than commands (“it builds” vs. “to build”, respectively). The basis of the way the architectures operate, however, is good - I’ll edit the post to fix builds-on to be the correct build-on.

[bmw]

Is this something that the snap store maintainers can manually help with?

The i386 Certbot snap I mentioned 4 months ago still exists and it is confusing some of our users.

[bmw]

I created a store requests thread about this at Manually delete snaps for an architecture.

[bmw]

Does anyone know how long the channel needs to stay closed for the the solution given in this thread to work?

In the past, I left the channel closed for less than 2 hours and it didn’t seem to help at all. Yesterday, I tried leaving the channel closed for roughly 10 hours which definitely helped but things are still behaving oddly. On a i386 system where we do not want to offer a Certbot snap, I see this:

# sudo snap install --classic certbot
error: snap "certbot" is not available on stable but is available to install on the following
       channels:

       edge       snap install --edge certbot

       Please be mindful pre-release channels may include features not completely tested or
       implemented. Get more information with 'snap info certbot'.
#  snap install --edge --classic certbot
error: snap "certbot" is not available on latest/edge but other tracks exist.

       Please be mindful that different tracks may include different features. Get more information
       with 'snap info certbot'.
# snap info certbot
error: no snap found for "certbot"