Latest continuous linuxdeployqt build does not work on Ubuntu 16.04 LTS and openSUSE Leap 15.0 #340
Comments
|
Yes, this seems to be added in b9b57e2. @probonopd I understand that you want to maximize compatibility with older distros, but please add an option to override this behavior. |
|
These kinds of annoyances don't exist in linuxdeploy for a reason... |
…yqt#340 Revert to building a separate debian source package
Yes, it is intended. The reasons are given in https://docs.appimage.org/introduction/concepts.html#build-on-old-systems-run-on-newer-systems:
I consider it good practice and want to encourage developers to develop against, and build for, the oldest still supported distributions. Mozilla, LibreOffice and many other great application projects do this. Personally I consider it "lazy" by an app developer to just develop for the latest and greatest distribution and tell users to "just upgrade your OS in order to use this application". Also, I don't have the capacity to test and support Which glibc version does Leap 15 come with? I am willing to discuss which glibc version should be the newest that we support. |
I think the right thing to do in cases like the one you are describing would be to bundle everything, so that the resulting AppImage would still run on all still-supported distributions. I did not have the time nor priority to implement this, since the kinds of applications we are targeting with linuxdeployqt understand that they should not use more recent build systems than the oldest still-supported release. I am open to adding options, as long as it is very clear that those options are neither recommended nor supported by me. As such, I would welcome pull requests that implement the following:
|
|
This should be at most a warning. It is perfectly useful to bundle up the dependencies to be able to run executables only on systems newer than the oldest ubuntu. This can be due to customers being on rhel/suse/etc. or simply because the payoff from rebuilding the world for the few users who refuse to use remotely recent distributions isn't worth it. Making the tool not work at all on anything but 14.04 simply means that people will stick with version 5 of linuxdeployqt forever or move to other less hostile tools. |
|
This broke our builds, (building on xenial), I think this should be a warning as well. Will revert to older linuxdeployqt in the short term, Ubuntu Trusty is EOL in 4 months. |
|
linuxdeployqt is a development tool. It should be usable across many distros and it should support different project needs. So if a project wants to be as compatible as possible then it shall go for a build chain that allows that, but projects which do not have that requirement shall have the option to still use linuxdeployqt on their newer systems. @probonopd openSUSE Leap 15.0 uses glibc 2.26. |
As said above, we want to encourage application developers to adopt a mindset that applications should be developed for the oldest still-supported (rather than the newest) distribution versions, so that the resulting binaries will work on all still-supported distribution releases. This is basic "platform thinking" and the way how backward compatibility works, on virtually any platform. Of course there may be legitimate situations in which it is not possible or desirable for an application to support all still-supported distribution releases, but those should really be the rare exception (e.g., for corporate deployments) than the rule. What I want to avoid is "careless" developers to inadvertently just build against whatever distribution release they happen to be running on their development machine out of convenience, not caring about users of other distribution releases. Because those are usually the same types of developers who will be surprised when their shiny new AppImage fails the automated tests for https://appimage.github.io, creating additional work to backport, re-build and re-test the AppImage that would have been avoidable if the application had been developed for and built on an older distribution release to begin with. For the rare exception cases, I would be willing to incorporate
This is a misunderstanding, and I have clarified the wording of the message. Once 14.04 is no longer supported as a distribution release, we may increase the "allowable" glibc version. It's only one quarter left until then... |
Clarification: I realize that the original message may have been misleading, hence I changed it. This is not about the brand of the distribution, this is simply about using an "old enough" distribution version (no matter what the brand) so that the resulting binaries will work on more than just the very latest distribution releases. |
|
The bug isn't that it said to use Ubuntu, the bug is that it refuses to work at all. Should it be an error if I attempt to deploy from my development machine to another machine I control for testing? Should it be an error if I run the build script (which builds, packages, and tests) locally? Should it be an error to build on the distribution that I know all of the users on my software are using? I would say that these are all very valid scenarios, but they are all currently disallowed by the tool. |
|
I wouldn’t call breaking stuff »encouragement«… |
|
I understand your point about making developers aware about the requirements against the platform they build on, which is I guess okay. However, being that restrictive and even breaking builds is IMAO going in the wrong direction, in particular for apps built on top of Qt - which this tool is supposed to bundle, right ;-) Up to now, I used the pre-build Qt binaries from here: https://launchpad.net/~beineri As you can see, recent Qt versions are no longer provided for Trusty. Because I want to use ideally the same Qt version for all target OSes for my apps, I had to upgrade to Xenial for the build. Which worked quite fine. Sure, the resulting AppImage might not have run on Trusty and comparable installations, but honestly, about which percentage of users are we talking here? I really think that a warning would be sufficient, or at least providing a switch to ignore the error. |
|
@probonopd how do you envision the update transition from 1404? Shall all developers update their deploy environments exactly the day the support ends? Not earlier because you disallow it, and not later, because it is unsupported then? |
|
@mhoeher currently trusty is the oldest still-supported LTS release of Ubuntu. So if you want your application to run on all still-supported releases of Ubuntu (which I think we should) and if you want to use the latest version of Qt, then we need to find the latest version of Qt compiled for the oldest still-supported LTS release of Ubuntu (currently: trusty). Have you asked beineri to provide one? |
|
@Optiligence migrating away from 14.04 can happen at any point after 14.04 is no longer supported. It does not have to happen on the day on which 14.04 is no longer supported, because users running later versions of the OS have no problems running applications compiled on earlier versions. However, the reverse is not true. |
|
Point in case:
|
|
CentOS 7 is super old, too. Older than trusty, isn't it? Not really a fair example. Highlighting the few edge cases in which things don't work is anyway unfair when you're not mentioning the other 99% where it just works. |
|
CentOS 7 will be supported (by them) until June 2024. |
|
What if someone would suddenly start to "support" (support is the wrong term here, most distro maintainers will probably agree, it's more like "push updates rarely, mostly when there's media coverage on a security issue...) Debian 1 or 2 again, would you go to every application and ask them to rewrite their entire software or implement horrible hacks to "make things work" again? Really, if stuff doesn't work on anything pre-2016 any more, it's not so much of an issue. As a developer, you don't necessarily want to work on such stuff, especially when doing it in your free time. You want to improve the software and implement more features, not spend time on maintaining some backwards compatibility for 0.01% of your potential market.... |
|
Sure, one needs to be somewhat pragmatic about it. Our current rule-of-thumb is to at least support all still-supported releases of Ubuntu. This is what we are also testing against in https://github.com/AppImage/appimage.github.io. People don't want to update their OS every 1-2 years. 3-4 years are much more realistic. Think institutions (universities, corporations,...). I know more than one large enterprise that is still running Windows 7, which was originally released 9 years ago. Only a couple of years ago the last Windows XP installations were migrated to 7. That's reality. |
|
But why prevent people from preparing to switch to xenial after nearly those 3 years you mentioned? Noone wants to force you on bionic or so. I bet trusty is the least interesting version for Canonical now... who knows "how" they realize this promise of "security updates"? Do they do anything? It's totally fine to switch to xenial now already. Upgrades have been possible since ~3 months after the release of xenial, as Ubuntu do it normally. Any sane user won't wait for the EOL date to upgrade... Any developer working with trusty now should have started to look into switching to xenial already 3 months ago, and <= 3 months to the EOL date is the perfect time to upgrade. Please don't introduce any annoyances like these. As the others pointed out, this should be at most a warning. I can recommend anyone who's annoyed by this to switch to linuxdeploy and linuxdeploy-plugin-qt... |
|
In fact, even CentOS 7 may be much "too new" for some users. I hear from credible sources that movie studios and the video effects industry are largely still using CentOS 6. For now, I think it is a reasonable compromise to at least support all still-supported releases of Ubuntu. And as said above, I am not against adding command line options for developers who know what they are doing that would allow to run on systems using newer glibc versions. |
|
Something is brewing...
This version of Inkscape has been compiled on Ubuntu 18.04 (because it cannot be compiled on older systems), and is nevertheless running on Ubuntu 14.04. So it can be done, but it has its downsides, too:
|
|
This is working so well it scares myself... Bleeding edge Inkscape 1.0 Alpha AppImage running on a 7-year old Linux distribution:
|
`linuxqtdeploy` recently add a test on the running system (libc version) and refuse to run if the libc is too recent. So we would need to run `linuxqtdeploy` only on ubuntu 14.04. However, we also need `qtwebengine5-dev` package whom is available only since ubuntu 18.04. While we find a solution (see comments in the linuxdeployqt issue), we have to allow the appimage build to fail. See probonopd/linuxdeployqt#340
|
@probonopd, all my ubuntu-18.04 GitHub runners got canceled, seems like this is the end for Ubuntu 18.04 on GitHub now, says https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/ |
Hm, or there is another reason... (and then it's still the end in two month...) |
...brownout |
Has anyone managed to build an Ubuntu18 container that is able to use aqt? I tried a lot, using different versions of python, pre-installing things, ... |
|
Are there any updates on this? Ubuntu 18.10 was removed from GitHub Actions. |
Check my previous comment: #340 (comment) |
|
If you want an example: Note that I had to fix several things in the AppImage myself to make it finally work, so there are two |
|
https://ubuntu.com/about/release-cycle is eol this month; will you finally remove this stupid requirement? |
I have it running with a single command: https://github.com/patrickelectric/qhot/blob/7539746aa9afb11fcb5f716111d0373763fd89a8/.github/workflows/release.yml#L71 |
I of course also started with one command. 😉 |
|
The requirement is already updated in continuous build(https://github.com/probonopd/linuxdeployqt/releases/tag/continuous). |
Do you have an open issue ? |
|
I don't. |
If you don't open issues to inform developers on don't send PRs, things will continue as it is. I would recommend to open an issue explaining what is going on. |
|
Very well, I've opened linuxdeploy/linuxdeploy-plugin-qt#140 then. 😉 |
|
help, im working on Ubuntu 22.04.1 LTS and cannot run linuxdeployqt.appimage it says p.s im a bit newbie to linux deployment so i dont know what i have to do |
|
As the message says, you need to run it on an older system. Currently Ubuntu 20.04 is the newest one which is allowed to run linuxdeployqt. This will change when Ubuntu 20.04 is no longer supported, which is in approximately a year. |
|
Help! I'm trying to run the AppImage from the continuous build(https://github.com/probonopd/linuxdeployqt/releases/tag/continuous) on my Fedora 34, and have encountered the following problem: linuxdeployqt (commit 6fcaf74), build 55 built on 2023-09-23 13:33:41 UTC It guides me here, and I want to know how to solve it. |
|
Have you read any of the previous comments, @AXIS5hacker ? |
|
Which part of
do you not understand? Genuinely curious, because I want to make the message as easy to understand as possible. |
Check my previous comment: #340 (comment) |
But test your AppImage on the oldest still supported LTS release of Ubuntu (assuming that is what your users might still be using) to make sure that it can run there. |
|
@AXIS5hacker |
and others
If I run
./linuxdeployqt-continuous-x86_64.AppImage --versionon m Ubuntu 16.04 LTS or openSUSE Leap 15.0 the following error is written.Two weeks ago the continuous build worked well on both machines. There are no issues with the latest release
linuxdeployqt-5-x86_64.AppImage.Is this behaviour intended?
The text was updated successfully, but these errors were encountered: