Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build .deb packages for older versions of glibc (e.g. Ubuntu 18.04) #36

Closed
lisenet opened this issue Sep 9, 2022 · 19 comments
Closed

Comments

@lisenet
Copy link

lisenet commented Sep 9, 2022

I think that .deb packages were built on Ubuntu 20.04 with a higher version of glibc which is not available on Ubuntu 18.04.

This breaks installation on Ubuntu 18.04.

A JavaScript error occurred in the main process
Uncaught Exception:
Error: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28' not found (required by /tmp/.org.chromium.Chromium.V1L3QF)
    at process.func [as dlopen] (node:electron/js2c/asar_bundle:5:1800)
    at Object.Module._extensions..node (node:internal/modules/cjs/loader:1170:18)
    at Object.func [as .node] (node:electron/js2c/asar_bundle:5:2027)
    at Module.load (node:internal/modules/cjs/loader:982:32)
    at Module._load (node:internal/modules/cjs/loader:823:12)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13331)
    at Module.require (node:internal/modules/cjs/loader:1006:19)
    at require (node:internal/modules/cjs/helpers:93:18)
    at Object.<anonymous> (/opt/OpenLens/resources/app.asar/node_modules/node-pty/lib/unixTerminal.js:26:11)
    at Module._compile (node:internal/modules/cjs/loader:1110:14)
@jkroepke
Copy link
Collaborator

jkroepke commented Sep 9, 2022

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

@lisenet
Copy link
Author

lisenet commented Sep 12, 2022

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

@jkroepke
Copy link
Collaborator

jkroepke commented Sep 12, 2022

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

@lisenet
Copy link
Author

lisenet commented Sep 12, 2022

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

@jkroepke
Copy link
Collaborator

jkroepke commented Sep 12, 2022

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

@lisenet
Copy link
Author

lisenet commented Sep 12, 2022

Is that because GitHub is owned by Microsoft?

@jkroepke
Copy link
Collaborator

jkroepke commented Sep 12, 2022

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.

@lisenet
Copy link
Author

lisenet commented Sep 12, 2022

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.

@jkroepke
Copy link
Collaborator

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?

@MuhammedKalkan
Copy link
Owner

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

@lisenet
Copy link
Author

lisenet commented Sep 12, 2022

"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.

@jkroepke
Copy link
Collaborator

@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.

@lisenet
Copy link
Author

lisenet commented Sep 12, 2022

"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.

@lisenet
Copy link
Author

lisenet commented Sep 12, 2022

"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.

@jkroepke
Copy link
Collaborator

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.

@lisenet
Copy link
Author

lisenet commented Sep 14, 2022

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

@xiloss
Copy link

xiloss commented Sep 15, 2022

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.

@jkroepke
Copy link
Collaborator

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.

@xiloss
Copy link

xiloss commented Sep 15, 2022

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants