chore: fix libssl dep

[pcnc]

Please go the the Preview tab and select the appropriate sub-template:

• Default
• Extension Upgrade

[jhf]

@pcnc After your change with --allow-downgrades libssl1.1="1.1.1f-1ubuntu2.20" then my build fails.
I removed that locally and now it's building here.
Why did you do the downgrade?
I mean, what problem does the downgrade resolve?
And why doesn't Supabase move to Ubuntu 22 LTS?

[pcnc]

Hi @jhf - sorry for the inconvenience!

Today (Feb 5th) at around 10:54 there was a version bump for libssl-dev in Postgres' apt archive repo, which seems to have generated a series of incompatibilities which lead to breaks when compiling against arm64, opposite to x86.

We've investigated options and are currently tackling this as part of #877

As for migrating to Ubuntu 22 LTS - it's on our roadmap for quite some time, though haven't been able to dedicate the proper time to it just yet!

[jhf]

Hi @jhf - sorry for the inconvenience!

It's ok, I just applied a local fix.

Today (Feb 5th) at around 10:54 there was a version bump for libssl-dev in Postgres' apt archive repo, which seems to have generated a series of incompatibilities which lead to breaks when compiling against arm64, opposite to x86.

I'm building my own version with a custom plugin.
I do build everything on my local M1 Mac with the command

docker buildx create --use
docker buildx build --push --target production --platform 'linux/arm64/v8,linux/amd64' --tag ghcr.io/veridit/supabase_postgres:latest .

As of today I could build both the arm64 and the amd64 image, when I removed the downgrade.

We've investigated options and are currently tackling this as part of #877

Where do you see what breaks?

As for migrating to Ubuntu 22 LTS - it's on our roadmap for quite some time, though haven't been able to dedicate the proper time to it just yet!

Yes, it takes time, is there a special problem you have with the upgrade?

[pcnc]

I do build everything on my local M1 Mac with the command
As of today I could build both the arm64 and the amd64 image, when I removed the downgrade.
Where do you see what breaks?

It's very odd as I, myself, couldn't reproduce the issue our GitHub Action runners encountered, when debugging locally (also using an M1 Mac).

I was able to reproduce, though, on an AWS Graviton ARM instance running Docker - again, very odd.

Where do you see what breaks?
The error is the following and can also be found here (this is a debug run, hence why the x86 build is missing):

5.363 Some packages could not be installed. This may mean that you have
5.363 requested an impossible situation or if you are using the unstable
5.363 distribution that some required packages have not yet been created
5.363 or been moved out of Incoming.
5.363 The following information may help to resolve the situation:
5.363 
5.363 The following packages have unmet dependencies:
5.556  libssl-dev : Depends: libssl1.1 (= 1.1.1f-1ubuntu2.20) but 1.1.1f-1ubuntu2.21 is to be installed
5.580 E: Unable to correct problems, you have held broken packages.

I was able to further pin down the cause by removing the cleanup step of the builder stage and targeting it in a build:

> docker build . -t supabase-postgres --target builder --platform linux/arm64/v8

And then running the built image and analyzing the .deb files temporarily placed in /tmp:

> docker run --rm -it --entrypoint bash supabase-postgres
> ls -lat /tmp/
root@6e192f498496:/tmp# ls -lat /tmp/
total 95624
drwxr-xr-x 1 root root        0 Feb  5 20:20 ..
drwxrwxrwt 1 root root     5918 Feb  5 19:38 .
-rw-r--r-- 1 root root  1459844 Feb  5 10:54 libssl-dev_1.1.1f-1ubuntu2.21_arm64.deb
-rw-r--r-- 1 root root  1105676 Jan 24 22:28 linux-libc-dev_5.4.0-170.188_arm64.deb
-rw-r--r-- 1 root root     3360 Jan 15 12:15 binutils_2.34-6ubuntu1.8_arm64.deb

The date and time correlates to the timeline of our builds starting to break, and the present .deb file is the same version as the one we've seen specified in the new error.

Yes, it takes time, is there a special problem you have with the upgrade?

No, not at all! It mostly has to do with planning and also doing it in such a way that would allow us to maintain operational cohesiveness across the entirety of active projects in order to be able to run maintenance and security patching across OS versions as similarly as is possible