Bforartists: [CI] Builds on Travis CI are all failing

Created on 16 Aug 2018  路  32Comments  路  Source: Bforartists/Bforartists

All the builds are red: https://travis-ci.org/Bforartists/Bforartists/builds

/opt/lib/blosc/lib/libblosc.so: undefined reference to '__cpu_model'

0 - task

All 32 comments

Thanks for the report. We are aware about this issue. MoxFulder has started this one as an experiment. But has no time at the moment to maintain it.

I would highly appreciate if the continuous builds could be made work, as they would serve as the basis for making AppImages. Thanks for your kind consideration!

Me too. But volunteer work is ... voluntary ^^

To the developer, binaries without source code are worthless.
To the user, source code without binaries is worthless.

So to be useful, developers need to put out source code that actually compiles :-)

It does. Travis fails here. Not the source code.

I would really love to help here. But i have no idea about Linux and travis :(

Travis fails here. Not the source code.

Let's say "this source code does not compile on the Ubuntu trusty environment that Travis CI uses" ;-)

But compiled fine at my Ubuntu in my VM ;)

As told, i have no idea what goes wrong here. I think it could be the travis settings in our repository. But i have no idea how this all works.

But compiled fine at my Ubuntu in my VM ;)

Ubuntu 14.04 (trusty)?

No, Ubuntu 14 doesn't work anymore, that's long deprecated. I compiled here at Ubuntu 17 before a few weeks. MoxFulder compiles at Arch.

That's the issue then. Since Ubuntu 14.04 is still an officially supported distribution, I don't understand why people see it as "deprecated".

It is deprecated. Development and fixes happens in newer versions. It's simply too old. Even Ubuntu 17 is a old version nowadays :)

One of the problems is the dependencies. Bforartists 1 requires Python 3.5, but Ubuntu 14 comes with Python 3.4. Blender 2.8 will require Python 3.7. And will most probably fail to compile at Ubuntu 17 then.

At the contrary, Ubuntu 15 made Python 3.4 deprecated. This version will not compile older software anymore that requires Python 3.4

Usually there is always just one stable linux version. And when a new version comes out then this new version becomes the stable version. There is a grace period until the former stable version becomes completely deprecated. I think that's two years or so. But i am no linux expert. And Ubuntu has a new version every year. Either way, with Ubuntu we are at Ubuntu 18 at the moment, with Ubuntu 19 coming soon. Maybe you mean the LTS versions. But Blender, and so also Bforartists, evolves, and requires the newest linux versions for their newest versions.

The support for TravisCI is deprecated for now due to the usage of AppVeyor. The problem with TravisCI is the usage of rather "old" Ubuntu versions. The support of 16.04 Docker image took a very long time and from the current point of view it is not clear when and whether there will be a 18.04 image at any time (https://github.com/travis-ci/travis-ci/issues/9460) [we had a discussion about exactly this issue this morning].

This leads to AppVeyor, which adds Linux support some months ago with an initial Ubuntu version of 16.04 and support for 18.04 coming soon (https://www.appveyor.com/blog/2018/05/15/appveyor-for-linux-is-generally-available/).

That's the reason for closing this issue. I will open a new issue regarding the unified AppVeyor integration.

That's actually a bad decision, since Ubuntu 14.04 is currently the oldest still-supported version and applications compiled on later versions will not be able to run on it. So Travis CI is doing the correct thing by offering the oldest still-supported release to compile stuff on.

Compiling on 16.04 (and possibly on 18.04 soon) does not offer any advantage to users of 16.04 or 18.04 but comes at a disadvantage of users of older versions of the distribution that will be excluded from running the compiled application.

Development and fixes happens in newer versions.

That is, again, unfortunate. In my personal opinion applications should always be developed against the "lowest common denominator" that can be assumed to be "there" on users' machines.

I see your point. But this doesn't really help us when the software itself does not even compile at this "oldest supported" linux version anymore. Linux has its drawback exactly in this area. Windows 7 or 10 will always run software made for Windows 7 or 10. Windows 10 even runs most of the Windows 7 software. But not Linux. You will run into the dependency hell sooner or later with older versions. And with Ubuntu 14 you do. It does not support the required Python version anymore.

To have compatibility with old Linux versions like Ubuntu 14 would have been a bonus. A luxury problem. At the moment we struggle to have a working linux build at all.

The initially mentioned problem:
/opt/lib/blosc/lib/libblosc.so: undefined reference to '__cpu_model'
is fixed for now. There seems to be a problem when using gcc-6 on 14.04. For now using old-fashioned 4.4 on 14.04 and 5 on 16.04.

Unfortunately AppVeyor has a time limitation of 1 hour per build, leading to problems when additionally calling install_deps.sh.
So, I'm currently reintegrating travis.yml, which is already building, with Ubuntu support for 14.04 and 16.04 (and experimental Mac).

In a latter step it will not be very hard to integrate AppImage support as well.

Linux has its drawback exactly in this area. Windows 7 or 10 will always run software made for Windows 7 or 10. Windows 10 even runs most of the Windows 7 software. But not Linux.

Perhaps this is a misconception. Like on Windows, an application compiled on an _older_ version of the Linux stack will run on a _newer_ version of the Linux stack, _if bundled properly_. But not the other way around, an application will normally not run on _older_ versions of the OS than what it was compiled on (this is true not only for the Linux stack but also for other OSes).

That's called forward compatibility. A Windows 10 software will not run at Windows 95. And a Ubuntu 18 software may not run at Ubuntu 14. Which is clear.

I talk about backwards compatibility. Windows 7 is now ten years old, and runs all Windows 7 software. And even Windows 10 runs still most Windows 95 software.

Ubuntu has a new major version every year. And does not run some older versions anymore. As told, they skipped Python 3.4 at one point. And when a software requires Python 3.4, then that was it. You are faster to simply install a newer Ubuntu version then.

Ubuntu has a new major version every year. And does not run some older versions anymore. As told, they skipped Python 3.4 at one point. And when a software requires Python 3.4, then that was it. You are faster to simply install a newer Ubuntu version then.

...that's where my _"if bundled properly"_ comes in: If you ship the version of Python that you need alongside your application, it will work just great. This is what many apps are doing, for example https://ultimaker.com/en/products/ultimaker-cura-software.

For AppImages, we recommend to never rely on the system Python.

Okay :)

Interestingly the builds for the repository Bforartists/Bforartists are receiving a time limitation while the one for my fork are working fine. The only notable difference is that my Github account is an Education account, does anyone of you have experience with that?

But the builds on Travis are working as expected again for Linux and Mac.

This was a task for Bforartists 1. We don't fix anything for Bforartists 1 anymore. So closing.

Please make a new task if the problem still exists with Bforartists 2

No, not just Bforartists 1, but __all__ Bforartists builds (no matter which branch or version), as can be seen here:

Okay, reopening.

The situation is still the same though. We won't fix anything for Bforartists 1 anymore. And we still don't have somebody to fix this issue here.

Thanks. I'd be fine if it could be fixed for Bforartists 2 then.

Error message is clean
The job exceeded the maximum time limit for jobs, and has been terminated.

I see that everything is being built from source using blenders script. Many deps can be installed using simple pip3 install so that would cut build times.

I have some progress with bforartists flatpak version by the way.

I noticed the Xcode 8 builds were failing due to this:

/Users/travis/Library/Developer/Xcode/GPUToolsAgent.sock: tar format cannot archive socket

I'm thinking this might be a cache config issue? If you exclude /Users/travis/Library/* it might fix this issue.

I have access to a Mac and build tools, if you guys need someone who can (occasionally) help troubleshoot, let me know! I'm not a pro at making Mac apps, but I do develop cross-platform tools on one.

Hi tsal,
Your help is more than welcome. Shall i add you as a collaborator? :)

Closing this issue. We use Github actions now. And there Linux and Mac compiles fine. Just Windows is failing, since the project is too big for Github Actions.

Sorry I never replied! This whole year has been out of whack! I'm glad your switch fixed some of your issues

No problem. Well, we switched from pest to cholera. For a while actions ran just fine. Then they changed something, and we never managed to fix that. Now everything is failing :D

No problem. Well, we switched from pest to cholera. For a while actions ran just fine. Then they changed something, and we never managed to fix that. Now everything is failing :D

I think I see the issue. You're using a python script to output to STDOUT to create an environment variable. That was turned off due to security issues recently, and a new method was provided.

Many thanks. Let's see if we can fix this :)

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ReinerBforartists picture ReinerBforartists  路  6Comments

Draise14 picture Draise14  路  6Comments

CyberFoxHax picture CyberFoxHax  路  6Comments

iyadahmed picture iyadahmed  路  7Comments

ReinerBforartists picture ReinerBforartists  路  6Comments