libvpx5 support missing

Product support balenaOS
1

I’m trying to build an image that uses libvpx5 and libcodec2. This was working as of a few weeks ago but has recently stopped working and I’m looking for suggestions on how to fix it.

The offending line is:

RUN install_packages apt-utils libvpx5 libcodec2

And the error is


[main]     Step 4/68 : RUN install_packages apt-utils libvpx5 libcodec2
[main]      ---> Running in 3864f8d65aaa
[main]     W: Skipping acquire of configured file 'ui/binary-armhf/Packages' as repository 'http://archive.raspberrypi.org/debian bullseye InRelease' doesn't have the component 'ui' (component misspelt in sources.list?)
[main]
[main]     Reading package lists...
[main]     Building dependency tree...
[main]     Reading state information...
[main]     E: Unable to locate package libvpx5
[main]     E: Unable to locate package libcodec2
[main]
[main]     apt failed, retrying

Thanks in advance

2

Sorry I should mention that I’m using this base image:

FROM balenalib/raspberrypi3-python:3.7
4

Hello @amarshall welcome to the balena forums!

I asked to the balena images team to see how we can help you more!

Let’s stay connected

9

Thanks. I wonder if the way that images are handled changed? I’m able to install the missing libraries using

FROM balenalib/raspberrypi3-debian:buster

before each install_package line so I have a workaround but would like to hear if something changed.

10

Found the issue. I had originally used

FROM balenalib/raspberrypi3-python:3.7

and changing it to

FROM balenalib/raspberrypi3-python:3.7-buster-build

seemed to have solved the problem.

11

Hey @amarshall, by pointing to balenalib/raspberrypi3-python:3.7 you are using a moving release and recently the default base image changed from buster to bullseye. An even more reliable way to pin to a known working image is something like 3.7.12-buster-build-20211014 which will never change.

13

Thanks @klutchell. How would I have known that the base image changed?

14

That’s a very good question @amarshall, and the short answer is not very easily. This is true of all Docker image tags, they are easily changed with no notice to the users.

For example, if you are using the official alpine:3 image, eventually it’s going to change from 3.14 to 3.15 and you would never know since you’ve only pinned to the 3 tag.
Even if you pin to alpine:3.14 that tag is likely to change when security fixes are introduced, etc.

The general advice is to pin to the longest version tag possible, or better yet one with a date stamp as these are unlikely to ever change. See the note in our documentation here:

You can also pin an image to it’s digest as outlined in the Docker documentation here:

Another thing you can do, is follow our base-images repo to see what changes and when:

1 Like
15

Thanks! That’s the help I needed.