search

probonopd / linuxdeployqt

Makes Linux applications self-contained by copying in the libraries and plugins that the application uses, and optionally generates an AppImage. Can be used for Qt and other applications
Other
2.22k stars 414 forks source link

Latest continuous linuxdeployqt build does not work on Ubuntu 16.04 LTS and openSUSE Leap 15.0 #340

Closed MrMontag closed 3 years ago

MrMontag commented 5 years ago

If I run ./linuxdeployqt-continuous-x86_64.AppImage --version on m Ubuntu 16.04 LTS or openSUSE Leap 15.0 the following error is written.

linuxdeployqt 5 (commit fc64c50), build 609 built on 2019-01-06 03:55:18 UTC
Please run on a system no newer than the oldest still-supported Ubuntu LTS release.
This is so that the resulting bundle can run on all still-supported releases of Ubuntu.

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?

tkashkin commented 5 years ago

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. I want to provide an AppImage of my app built on 18.04. I don't want to support ancient distros like 14.04 and I expect users to have a recent enough distro to run my app.

TheAssassin commented 5 years ago

These kinds of annoyances don't exist in linuxdeploy for a reason...

probonopd commented 5 years ago

Is this behaviour intended?

Yes, it is intended. The reasons are given in https://docs.appimage.org/introduction/concepts.html#build-on-old-systems-run-on-newer-systems:

It is considered best practice to develop and compile the application on the oldest still-supported Linux distribution that we can assume users to still use. For example, the oldest still-supported LTS release of Ubuntu is a good choice to develop applications against and build applications on. (...)

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 linuxdeployqt on all kinds of distributions.

Which glibc version does Leap 15 come with? I am willing to discuss which glibc version should be the newest that we support.

probonopd commented 5 years ago

please add an option to override this behavior

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:

BumblingCoder commented 5 years ago

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.

dagheyman commented 5 years ago

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.

MrMontag commented 5 years ago

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.

probonopd commented 5 years ago

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.

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 -unsupported-bundle-everything and -unsupported-allow-new-glibc options as mentioned above, if someone cares enough to send a PR. Again, my point is not to prevent anyone from doing anything, but to increase awareness that it is really a bad idea to build on bleeding edge build systems, because the resulting binaries will fail on some still-supported distributions, and will fail the tests for https://appimage.github.io/.

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 is a misunderstanding, and I have clarified the wording of the message. linuxdeployqt will run on systems that have no newer glibc version than what the oldest still-supported mainstream distribution (currently: Ubuntu 14.04) ships with. It is not limited to Ubuntu or any particular Ubuntu release; all we want to avoid is people using it on "too new" build systems (no matter which distribution).

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

probonopd commented 5 years ago

This can be due to customers being on rhel/suse/etc.

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.

BumblingCoder commented 5 years ago

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.

Optiligence commented 5 years ago

I wouldn’t call breaking stuff »encouragement«… Our build is tested on the systems it has to work on. We use this tool to ease dependency collection. It would be appreciated if it remained usable as that.

mhoeher commented 5 years ago

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.

Optiligence commented 5 years ago

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

probonopd commented 5 years ago

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

probonopd commented 5 years ago

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

probonopd commented 5 years ago

Point in case: https://twitter.com/chaz_6/status/1084123390376640514

TheAssassin commented 5 years ago

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.

probonopd commented 5 years ago

CentOS 7 will be supported (by them) until June 2024.

TheAssassin commented 5 years ago

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

probonopd commented 5 years ago

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.

TheAssassin commented 5 years ago

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

probonopd commented 5 years ago

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.

probonopd commented 5 years ago

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:

probonopd commented 5 years ago

This is working so well it scares myself... Bleeding edge Inkscape 1.0 Alpha AppImage running on a 7-year old Linux distribution:

patrickelectric commented 5 years ago

@probonopd ty for -unsupported-allow-new-glibc.

TheAssassin commented 5 years ago

This won't have any really positive effects... now, people will just always put this flag into their build scripts. This kind of "user infantalizing" is never a good idea. I try to educate users and show them where the issues are and how they can do better. That's more effective in the long term.

patrickelectric commented 5 years ago

@TheAssassin At least it helps to not freeze the development with linuxdeployqt-5, but I'm doing some tests with linuxdeploy and planning to move to it.

TheAssassin commented 5 years ago

@patrickelectric my point is that the introduction of the error was a mistake and doesn't educate but only annoy users.

probonopd commented 5 years ago

I want to annoy developers who do not care for any users but those running the very latest distributions. Because it annoys me having to explain each developer individually why their shiny new "AppImage does not work" (as users say).

On a related note: A quick survey for everyone who gave feedback in this ticket.

Since you commented here, you are probably deploying an application that was compiled on a recent operating system release, which likely means that your users currently can run your application only on recent operating system releases. I understand that you deem the additional effort of backporting your application not worth the effort. So here are my questions:

  1. Once 18.04 becomes the oldest still-supported Ubuntu release, will you keep developing for and building on 18.04 version until it, too, is no longer supported? (This means you won't have the backporting work, but it does mean that you cannot move to build systems newer than 18.04 until it, too, is no longer supported

[ ] yes [ ] no, because __

  1. If there was an easy way to make applications compiled on new OS releases runnable on older OSes (at the expense of making the AppImages bigger), would you consider using it?

[ ] no [ ] yes, if the size of the AppImage will not grow more than 5 MB [ ] yes, if the size of the AppImage will not grow more than 10 MB [ ] yes, if the size of the AppImage will not grow more than 15 MB

  1. If you answered both questions with "yes", would the availability of the option described in question 2 change your mind on question 1, in other words - would you then no longer keep developing for and building on 18.04 version until it, too, is no longer supported?

[ ] yes [ ] no

TheAssassin commented 5 years ago

This is too short-sighted. There's a difference between "runs" and "is good"... I don't want people to bundle libc, libstdc++, libssl etc. That's a security nightmare...

probonopd commented 5 years ago

There is also a difference in what "security" means between, say, a browser, and, say, a drawing application. And if I am running an application that bundles this stuff on, say, Ubuntu 12.04, then it is actually probably more secure than what came with the OS.

BumblingCoder commented 5 years ago

Honestly, I don't care about what platforms Canonical, Red Hat, SUSE, or any other distro provider are occasionally providing security patches for. I develop for systems that I care about or am paid to care about. For hobby projects it simply isn't worth my time to care about ancient versions of ubuntu for software that there is exactly one user (me) of. For stuff that I am paid to care about I know what systems my users are running and will build for those platforms regardless of what packaging tools have to say about it.

BumblingCoder commented 5 years ago

There is also a difference in what "security" means between, say, a browser, and, say, a drawing application.

Any program that touches the network or has the possibility of opening untrusted files (which is to say, all programs) needs to care about security at some level.

BumblingCoder commented 5 years ago

This is too short-sighted. There's a difference between "runs" and "is good"... I don't want people to bundle libc, libstdc++, libssl etc. That's a security nightmare...

Bundling libstdc++ is pretty common when targeting old platforms though, unless the software restricts itself to not using modern language features so that it can be built with whatever old compiler was native to the distro. Is there a recommended alternative? (I agree about libc and libssl though.)

probonopd commented 5 years ago

Looks like OBS switched the AppImage builds to Leap 15.0 at some point (something I am not too thrilled about but I guess they had their reasons for). Hence I have bumped the allowable glibc version. This means that AppImages built on OBS will no longer run on distributions like Ubuntu 14.04.

adrianschroeter commented 5 years ago

@probonopd our default is still leap 42.3 (we have a 15.0 one in addition)

VioletGiraffe commented 5 years ago

This brick wall that I can't opt out of is ruining your otherwise very good and useful tool. There are some thoughtful comments above on why this is bad. Did you notice pretty much no one voiced support for this restriction?

P. S. Took me a while to find the undocumented -unsupported-allow-new-glibc flag, upwards of half an hour. Great job wasting my time (which, as you know, is money...). That pull request with the updated message mentioning this option is really needed.

emericg commented 5 years ago

You can (mostly) opt out, just configure your scripts to use the latest "usable" version, the release 5: https://github.com/probonopd/linuxdeployqt/releases/tag/5

probonopd commented 5 years ago

Please be aware that -unsupported-allow-new-glibc will let you produce AppImages that won't run on all still-supported releases of Ubuntu, and as such may waste your customers'/users' time (and money). Also, such AppImages won't pass the tests for https://appimage.github.io/.

So the best option is to build on the oldest still-supported release of Ubuntu. Everything else is just an unsupported workaround and something we don't want to encourage.

There is a trade-off here: To make it really easy for users we do need to make it a little bit harder for developers.

emericg commented 5 years ago

Good to know about the glibc flag. Where can we track what is the latest supported version then? (and associated major distribs) That should probably be in the readme.

With all due respect, building modern softwares on ubuntu 14 is not a small inconvenience, it's a major pain. Building latest Qt, ffmpeg (and my god the dependencies), supporting 6+ yo versions of cmake, and so much more... Yeah it's some serious work. And yes I need latest Qt versions. I actually need many features from the next version(s)...

Also appimage.github.io is way prettier than last time I went there, well done! It could really use some more responsive design though, 940px wide is not really wide enough by today's standard.

VioletGiraffe commented 5 years ago

@probonopd : I understand your reasoning, but in my particular case I know very well my users will be running at least 16.04. There's no need for the development to be any harder than it absolutely has to be.

probonopd commented 5 years ago

Where can we track what is the latest supported version then?

We recommend to target the oldest still-supported Ubuntu LTS release. https://wiki.ubuntu.com/Releases

In April, Trusty will be eol so you can develop for Xenial then.

With all due respect, building modern softwares on ubuntu 14 is not a small inconvenience, it's a major pain. Building latest Qt, ffmpeg (and my god the dependencies), supporting 6+ yo versions of cmake, and so much more... Yeah it's some serious work. And yes I need latest Qt versions. I actually need many features from the next version(s)...

It is only "hard" if developers don't start with developing for those releases to begin with, and try to "backport" retroactively. Pro tip: Save the pain and develop against the oldest still-supported LTS to begin with, then it's not so much hassle.

Also appimage.github.io is way prettier than last time I went there, well done! It could really use some more responsive design though, 940px wide is not really wide enough by today's standard.

Pull requests welcome. It's just a Jekyll site.

probonopd commented 5 years ago

@probonopd : I understand your reasoning, but in my particular case I know very well my users will be running at least 16.04.

Yes, just wait until April, then you're golden because at that point 16.04 will be the oldest still-supported release. But please don't develop against a newer release than 16.04 before April 2021, when 16.04 will be EOL.

https://wiki.ubuntu.com/Releases

BumblingCoder commented 5 years ago
  1. The fact that Canonical provides occasional security patches for an ancient distribution is a poor reason to require that unaffiliated developers rebuild the world for every project. If people want to use old software let them use old software.
  2. The correct time to update build images to a new distribution is immediately after the last release that will target the old distribution. The only reason to have build images still on ubuntu 14.04 at this point is if a new release is planned in the next month. Otherwise it makes more sense to update the image to build and test on the distribution that will be supported for the release. Requiring a flag to the build tool just means that this flag will become a permanent option in a bunch of build scripts, and annoy developers who forget it.
emericg commented 5 years ago

We recommend to target the oldest still-supported Ubuntu LTS release. https://wiki.ubuntu.com/Releases

Then again, mention it explicitly. I stumbled upon that page by googling before your comment, https://www.ubuntu.com/about/release-cycle and while I saw 14.04 would stop being supported around Q2 2019, no date was mentionned.

It is only "hard" if developers don't start with developing for those releases to begin with, and try to "backport" retroactively. Pro tip: Save the pain and develop against the oldest still-supported LTS to begin with, then it's not so much hassle.

I also understand the reasoning, but then again, developing on 6yo softwares is not really my thing. Qt widgets might be dead since that time, Qt QML is in active development. I'm looking forward to features that might be in Qt 5.14, not the other way around. It's absolute madness to think that I have an easier time setting up CI and packaging my applications for linux than for macOS and windows!

probonopd commented 5 years ago

Then again, mention it explicitly.

Updated the README accordingly: https://github.com/probonopd/linuxdeployqt/blob/master/README.md#a-note-on-binary-compatibility

It is fine to use a later Qt, e.g., our examples in the README explicitly mention https://launchpad.net/~beineri. It is fine to use a later Qt because a subset of Qt will be bundled with your application, and we are not using the Qt that came with the system.

probonopd commented 5 years ago

The fact that Canonical provides occasional security patches for an ancient distribution is a poor reason to require that unaffiliated developers rebuild the world for every project. If people want to use old software let them use old software.

People want to use the latest versions of applications without having to update the base system (distribution) every couple of years. (I personally know people who are still running Windows XP and Ubuntu Gutsy and are perfectly happy with it. This may be an extreme example but you get the idea.) Many organizations (enterprises, universities etc.) simply cannot afford to audit, deploy, and support OS updates all the time.

Hence we want to encourage developers build on the oldest still-supported distribution release. It is no additional work if during development if the oldest still-supported distribution release is targeted from the beginning. It is only a big hassle if developers upgrade their development machines to the latest bleeding edge OS version and initially develop against that, only to find out later that users and customers don't all have the latest bleeding edge OS version.

This is something I feel strongly about. The AppImage format epecially appeals to users who are not administrators, users who do not have root rights, users who cannot simply upgrade the whole system. Where I work, for example, machines were upgraded to Windows 10 only very recently.

Of course the developer in the end is the one who decides, but at least we would like the developer make an informed decision (rather than a merely "random" one driven by the fact that they personally are using the latest OS version themselves).

emericg commented 5 years ago

It is fine to use a later Qt, e.g., our examples in the README explicitly mention https://launchpad.net/~beineri

Yes, I already do, but even beineri stopped supporting trusty last year, two Qt releases ago ><

Updated the README accordingly

Great! That will make things more clear.

I personally know people who are still running Windows XP and Ubuntu Gutsy and are perfectly happy with it.

I do get the idea, that is their choice and they have every right to do so. I suspect that's not the kind of users that would complain if a software that I started developing this year doesn't work on their OS.

I maintain various softwares. My biggest python software still supports python 2, because it's not that hard to do. My Qt Widgets softwares are using travis CI on ubuntu 14.04, because it's not that hard to do either (and actually cmake version is already a pain). My most recent softwares, with multimedias, bluetooth, QML and whatnot? Men, that's just too much work, I just won't do it. Me personally, I use Arch Linux. And I'm not sorry about that.

This is something I feel strongly about

And we can see that ^^ I really like the turnkey aspect of the AppImage format too. I will keep using it. It's also really easy to package (well, present issue excluded :p) thanks to great tooling. It's not an insane duplication of the package manager of the OS like packagekit does (which I really don't understand).

MyraBaba commented 5 years ago

@VioletGiraffe

How you run ? I have still error. ubuntu 18.04 Qt5.12 :

which version I can use ? 


./linuxdeployqt-continuous-x86_64.AppImage -unsupported-allow-new-glibc

linuxdeployqt 6 (commit e8148f3), build 671 built on 2019-03-30 18:35:26 UTC
ERROR: The host system is too new.
Please run on a system with a glibc version no newer than what comes with the oldest
still-supported mainstream distribution, which currently is glibc 2.20.
This is so that the resulting bundle will work on most still-supported Linux distributions.
For more information, please see
https://github.com/probonopd/linuxdeployqt/issues/340
MyraBaba commented 5 years ago

@VioletGiraffe

I ran with flag as below : still gives error. Do I need to use specific version . ? ./linuxdeployqt-continuous-x86_64.AppImage -unsupported-allow-new-glibc

linuxdeployqt 6 (commit e8148f3), build 671 built on 2019-03-30 18:35:26 UTC ERROR: The host system is too new. Please run on a system with a glibc version no newer than what comes with the oldest still-supported mainstream distribution, which currently is glibc 2.20. This is so that the resulting bundle will work on most still-supported Linux distributions. For more information, please see https://github.com/probonopd/linuxdeployqt/issues/340