search

blue-build / modules

BlueBuild standard modules used for building your Atomic Images
Apache License 2.0
23 stars 4 forks source link

failed to solve: ghcr.io/ublue-os/akmods-extra:fsync-3 #322

Closed kevindurb closed 1 month ago

kevindurb commented 2 months ago

Getting a new error in my build all of a sudden:

ERROR: failed to solve: ghcr.io/ublue-os/akmods-extra:fsync-3: failed to resolve source metadata for ghcr.io/ublue-os/akmods-extra:fsync-3: ghcr.io/ublue-os/akmods-extra:fsync-3: not found

Heres my recipe:

---
# yaml-language-server: $schema=https://schema.blue-build.org/recipe-v1.json
name: htpc
description: My personal htpc image

base-image: ghcr.io/ublue-os/bazzite-nvidia
image-version: '40'

modules:
  - type: rpm-ostree
    repos: []
    install:
      - snapd

  - type: default-flatpaks
    notify: true
    system:
      install:
        - org.mozilla.firefox
      remove: []
    user:
      install:
        - com.bitwarden.desktop
        - com.freerdp.FreeRDP
        - com.moonlight_stream.Moonlight
        - io.github.elevenhsoft.WebApps
        - net.retrodeck.retrodeck
        - org.fedoraproject.MediaWriter
        - org.prismlauncher.PrismLauncher
        - org.videolan.VLC
        - com.spotify.Client
        - com.github.tchx84.Flatseal

  - type: akmods
    base: fsync
    install:
      - rtl88xxau

  - type: signing

Full build output should be visible here: https://github.com/kevindurb/ublue/actions/runs/10402227349/job/28806309871

xynydev commented 2 months ago

Weird. The format of the tag is supposed to be fsync-<fedoraversion> (for example fsync-40). For some reason CLI is gathering the fedora version of your base image as 3...

This appears to be due to a change in Bazzite labeling. The bazzite-nvidia image uses "org.opencontainers.image.version": "v3.6-40.20240815.0", while the other images stilll use "org.opencontainers.image.version": "40.20240815.0",. This means we're parsing it wrong.

I'm unsure how to mitigate this @gmpinder? Maybe we need some way to manually specify the image version when errors like this arise? Or try to figure out a better way to parse the label, maybe by finding the whole 40.20240815.0 (VV.YYMMDD.N) string in it?

This PR seems to be the culprit. We can always complain upstream, but that wont always work (even if it did even once), because image maintainers should and do have the right to relabel their images, and we should find a way to mitigate the adverse effects that.

gmpinder commented 2 months ago

Yeah, I think complaining upstream would be the best option. They had a similar situation when Bazzite for Fedora version 40 came out. I put a ticket in and they got it resolved. I guess they'll have to do it again.

fiftydinar commented 1 month ago

According to the linked issue, it's fixed?

If not please reopen