Build .deb packages for older versions of glibc (e.g. Ubuntu 18.04) about openlens HOT 19 CLOSED

Could you test, if the deb from here works for you? https://github.com/jkroepke/OpenLens/releases/tag/v6.0.2

from openlens.

Personally, I compiled every different binary in different container images; it's easier and the process is quite simple, you just have to ensure you have the right dependencies; just clone the open-lens branch in containers having the right operating system, take care of installing the right dependencies (node 14-16, developer tools and so on), modify the package.json to target only the binary packages for that specific container OS version and that's it, you run make and you have everything in your dist folder; if you use disk volumes you can have parallel builds. For macOS, one can use a mac if having it, or also the emulation on vbox/qemu sandboxing and that's it.
To inspire everyone, the current repo GitHub pipeline shows a clear guideline of how to do that also on the CI side
https://github.com/MuhammedKalkan/OpenLens/blob/main/.github/workflows/main.yml

The reverted arm64 option can be built using the qemu/kvm options to run a container the same way, i.e. check arm64v8-debian-qemu or other bundles.
Could be a nice-to-have here in this repo...

My question is more for Lens generally, I understand they decided to split their project into open and commercial, but why they removed all the old endpoints for downloads? Very bad.
Aaah, I forgot, for building windows ??? The answer is obvious -> I don't do windows.

from openlens.

@jkroepke the .deb build from that repo does not break installation on Ubuntu 18.04, thank you.

from openlens.

So building on the (deprecated) ubuntu-18.04 would resolve the issue.

from openlens.

Ubuntu 18.04 LTS is a supported vendor release until at least April 30, 2023 (also officially supported by Dell).

from openlens.

But its deprecated by GitHub, not sure how long the runner flavor is available.

from openlens.

Is that because GitHub is owned by Microsoft?

from openlens.

Is that because GitHub is owned by Microsoft?

See: actions/runner-images#6002

They also do this for windows based runners. actions/runner-images#4312

We maintain the latest two stable versions of any given OS version.

From my point of view, this is a valid standpoint. The own support policy must be not match with Canonical once.

from openlens.

I see, fair enough, as Ubuntu 18.04 is approaching the end of its support cycle. Target date is April 1st, 2023 according to that link, which is half a year away anyway.

from openlens.

This true, but also take care of

To raise awareness of the upcoming removal, we will temporarily fail jobs using Ubuntu 18.04.

@MuhammedKalkan what did you think?

from openlens.

This has been failing on my Elementry OS 5 which uses Ubuntu 18 core. To be honest, i believe it is not very productive to support almost outdated OS. Also this is not the only way to use Lens on that OS. You can always build for your own version of OS. So i would pass this one

from openlens.

"it is not very productive to support almost outdated OS". Define "almost outdated". Is CentOS 7 almost outdated?

While I see your point (it's inconvenient, I get it), I don't think that dropping support for officially supported and non-EOL operating systems is the right approach. If your intent is to build binaries for specific versions of OS that you consider current, then so be it, but your should make it clear.

As you said, I can always build my own OpenLens binaries, that's not a problem at all. I am about to do that as I cannot use yours anyway, but it's not the point. I thought your project would save me time required to do it, which I believe was your intent as well by creating this repo. Otherwise, as you said, everyone can always build for their own versions of OS.

from openlens.

@lisenet could you provide instruction to build OpenLens for Ubuntu 18.04 on Ubuntu 20.04? I guess that would resolve the issue.

Since GitHub already deprecated ubuntu-18.04, including longer queue times and expectable brownout periods, I would not like to switch the runner image to ubuntu-18.04.

What about the official Lens binaries. Did they work in Ubuntu 18.04?

What about the AppImage? It should include the correct glibc.

Is CentOS 7 almost outdated?

From developer perspective. yes. CentOS Stream 9 is available and I see no reason why I should depend agist an 8 years old glibc library. I guess for such cases. AppImage or snap packages are the way to go.

from openlens.

"What about the official Lens binaries. Did they work in Ubuntu 18.04?" - they do indeed, I've been using their official .deb build up until the point they wanted me to sign up for their account.

from openlens.

"could you provide instruction to build OpenLens for Ubuntu 18.04 on Ubuntu 20.04?" - I don't have those I'm afraid as I don't build OpenLens for Ubuntu 18.04 on Ubuntu 20.04, I build OpenLens for Ubuntu 18.04 on Ubuntu 18.04. It's not a problem really as I can continue building it locally, and when I migrate to Ubuntu 20.04 next year, I will build on 20.04.

from openlens.

I see only 2 solutions here. Run OpenLens on a deprecated runner flavor or Ubuntu 18.04 users have to use AppImage or snap approach.

from openlens.

Building locally on Ubuntu 18.04 therefore this is no longer required. Feel free to close the issue.

from openlens.

Since its close, we can go offtopic.

My question is more for Lens generally, I understand they decided to split their project in open and commercial, but why they removed all the old endpoints for downloads ? Very bad.

Yes and No. The split was done with version 5 of Lens. At least from version 5 everyone was used the commercial version called "Lens". builds for OpenLens was never provided.

Then the developer start to integrate Lens Cloud, Lens Account and make it as requirements. With version 6, they also add payable requirements.

from openlens.

Hey, @jkroepke thank you for answering and for the off-topic. That clarification makes sense, you should put that in the current README file, as a brief intro. Also, the open-lens initiative in that case has a nicer shape. It's the clear intention of maintaining the options available for everyone.

from openlens.