Automated build for linux/arm/v6

[leleobhz]

Hello!

This change allow Raspberry Pi 1/2 to be used with this image. I see some other projects also pushing linux/arm/v5 but I don't see reason to do this since my Raspberry Pi 1 asked for linux/arm/v6 image:

root@pivovo:~/docker-cups# docker compose up -d
[+] Running 0/1
 ⠙ cups Pulling                                                                                                                                                          8.1s
no matching manifest for linux/arm/v6 in the manifest list entries

Can you please merge it?

[anujdatar]

Hi, I woulld be open to merge this, but I have no way of testing this consistently. I don't have an arm v6 board anymore. I think alpine linux based containers sometimes have build issues on v6, based on issue #6. And I've also had problems with Alpine on arm v7 before.

At the moment I only have x86, and armv8 boards for testing. Did you try to build this container on your Pi 1? Did all the packages work without issues?

One thing you could do in the meantime is clone this repo and then use a docker-compose.yml file to build the container on the fly when you deploy.

Edit: I got my arm versions mixed up.. I guess Pi Zero is v6, and everything Pi3 and up is 32/64 bit arm v8+

[leleobhz]

Hi, I woulld be open to merge this, but I have no way of testing this consistently. I don't have an arm v6 board anymore. I think alpine linux based containers sometimes have build issues on v6, based on issue #6. And I've also had problems with Alpine on arm v7 before.

At the moment I only have x86, and armv8 boards for testing. Did you try to build this container on your Pi 1? Did all the packages work without issues?

One thing you could do in the meantime is clone this repo and then use a docker-compose.yml file to build the container on the fly when you deploy.

Edit: I got my arm versions mixed up.. I guess Pi Zero is v6, and everything Pi3 and up is 32/64 bit arm v8+

Hello @anujdatar !

Thank you for awnsering! I share you concern about build issues on containers. About armv6/v7, since this project uses Debian as base image and CUPS in usage is the original build from debian, i think there is no issue with image while debian supports ARM and supports ARM EABI officially.

Also, I tested this image on my armv6 (A Raspberry Pi 1) with BUILD_FORMAT=docker podman build --platform linux/arm/v6 --tag anujdatar/cups:latest . as build command. I'm currently running you Dockerfile on my v6 sucessfully (And also integrated avahi-daemon from host in it):

That all said, I think for this container specifically the question about "work on arm" is a Debian ARM EABI support matter - if works on Debian Stable, will work here too. I also defend - as proofed - that very old Raspiberries can be used as Simple servers (Like this running NUT for nobreak monitoring + CUPS as print server).

About you concern being able to test yourself, I agree with you caution and I suggest (And can commit to README.md) a warning about linux/arm/v6 being a best-effort and untested build by lacking of hardware - if you want to.

What do you think about these points?

[anujdatar]

Hey,

Thanks for letting me know. I have been meaning to add avahi-daemon to the container and see if the printer is discoverable from MacOS. I'll try it out over the weekend and merge the PR.

Edit: Also, I had forgotten this build was based on Debian. I got it confused with my other DDNS containers that use Alpine. And I agree, it should work as long as Debian and all the required packages support ARMv6. Same goes for Alpine. But I remember this edge case where Alpine supported ARM, but the time package or something was broken, that caused all my arm build to fail.

Anuj

[leleobhz]

Hey,

Thanks for letting me know. I have been meaning to add avahi-daemon to the container and see if the printer is discoverable from MacOS. I'll try it out over the weekend and merge the PR.

Hello @anujdatar

I suggest instead to add avahi to container, to use docker-compose to document how to integrate 2 containers and use something like https://github.com/flungo-docker/avahi with this job. My only concern is avahi - for simplicity - must run with --network=host (Or network_mode: host in compose). Avahi socket can be shared with cups container using docker volumes.

But I remember this edge case where Alpine supported ARM.

I usually avoid alpine build. Sure debian:stable-slim and Redhat UBI images does not comes into a bunch of bytes as alpine, but headaches concerning musl issues usually do a lot of harm. A very very minimal ubi image have 6mb of size: https://catalog.redhat.com/software/containers/ubi9/ubi-micro/615bdf943f6014fa45ae1b58?architecture=amd64&image=6571624b160f22feda11a798 and debian:stable-slim arround 30mb

And some images (flanneld image is a good example) does have only the specific binary thats used for, no coreutils, notting. It's a option for sizing too.

[anujdatar]

Hi @leleobhz

I suggest instead to add avahi to container, to use docker-compose to document how to integrate 2 containers and use something like https://github.com/flungo-docker/avahi with this job.

Interesting, I had not thought of that. I'll take a look. Thanks.

I usually avoid alpine build. Sure debian:stable-slim and Redhat UBI images does not comes into a bunch of bytes as alpine, but headaches concerning musl issues usually do a lot of harm.

Yeah, I have run into musl issues before too. But I like alpine containers if I am just going to run simple bash scripts, curl or wget updates to some server somewhere (DDNS, Discord hooks, etc). Otherwise I stick to debian:slim.

Or like the avahi-docker container you suggested. It's basically a bash script that sets all the config values for avahi. That uses alpine too.

[leleobhz]

Hi @leleobhz

Hi @anujdatar

Yeah, I have run into musl issues before too. But I like alpine containers if I am just going to run simple bash scripts, curl or wget updates to some server somewhere (DDNS, Discord hooks, etc). Otherwise I stick to debian:slim.

My golden-rule is:

• No heavy malloc() dependent (Databases are greatest examples);
• Notting that can use SSL at least once in their live;
• No Python.

Or like the avahi-docker container you suggested. It's basically a bash script that sets all the config values for avahi. That uses alpine too.

I can also fork it and implement a ci/cd using debian-slim. I can also test it on my little print server. I'll try something on weekend.