Linux package repositories

[mia-0]

Just wanted to let you know that I’m maintaining packages for Debian 9.0 (Stretch), Fedora 26 and Rawhide, openSUSE Leap 42.1/42.2/42.3 and Tumbleweed (including ARM/PPC), as well as Ubuntu 17.04 and AppImages for all the other distros at openSUSE’s Open Build Service:

https://software.opensuse.org//download.html?project=home%3Alachs0r%3Amandelbulber2&package=mandelbulber2

AppImages are here (including zsync files for delta updates): http://download.opensuse.org/repositories/home:/lachs0r:/mandelbulber2/AppImage/

These are packages of the latest release, including OpenCL support. Feel free to link to these builds; I will keep them up to date.

[ghost]

muchos gracias!

[ghost]

Please provide additional engineering documentation for review.
Do you have any scripts or files worth adding to repo for these build configs?
Please explain like I am 5 years old, the opensuse build architecture, I am unfamiliar and request full reasoning.

[mia-0]

Not sure what to explain. Build ingredients are here: https://build.opensuse.org/package/show/home:lachs0r:mandelbulber2/mandelbulber2 Debian/Ubuntu: debian.tar.gz and mandelbulber2.dsc Fedora/openSUSE: mandelbulber2.spec AppImage: appimage.yml, mandelbulber2.obsinfo Common: mandelbulber2.changes There’s not much magic involved. The build instructions are almost the same for all distros, but specific to their package formats. OBS just takes these instructions, builds the packages using native tools running on virtual machines, and generates repositories. Something I’d like to see for packaging is a proper CMake install rule using the correct paths, so I can skip the manual copying and .desktop file mangling in the install section. OBS also allows building snapshots from git repositories. GitHub has an integration for this, so it can trigger a build whenever commits are pushed.

[ghost]

Great insight, the snapshot CI sounds useful. Would you like to modify the cmake file and become a contributor?

[mia-0]

Yeah, I’ll look into it. Shouldn’t be too hard to fix.

[ghost]

Looking forward to your pull request. Thanks!

[probonopd]

Great job on building AppImages on OBS! 👍

Minor issue, I am getting

Error: Can't open file /usr/share/mandelbulber2/formula/ui/fractal_mandelbulb.ui
Fractal ui file can't be loaded

/usr is not where things are in an AppImage. Hence the application should, rather than trying to load things from /usr, try to load things from "relative to itself". Let me know if you need help on doing this in Qt.

[mia-0]

Thanks for making it possible!
Yeah, I’ve noticed this with other applications. I didn’t get around to working on the build system yet, but I’ll do that later today, and fix this in the process.

[zebastian]

@probonopd
we determine the shareddir in the following way:

#ifdef _WIN32 /* WINDOWS */
	systemData.sharedDir = QDir::toNativeSeparators(QDir::currentPath() + QDir::separator());
#else
	systemData.sharedDir = QDir::toNativeSeparators(QString(SHARED_DIR) + QDir::separator());
#endif /* WINDOWS */

see usage in https://github.com/buddhi1980/mandelbulber2/blob/master/mandelbulber2/src/system.cpp

When we can determine this path with appimages somewhere else it should be fine. We only need to make sure, that it will still be compatible with windows, osx, and simple installed version under linux.

[probonopd]

You need to make the path relative to the running executable, e.g., using QCoreApplication::applicationDirPath(). See http://archives.seul.org/tor/cvs/Mar-2012/msg00886.html for an example.

[zebastian]

hmm, is there no dedicated path for the shared data of the program?
Some kind of environment variable, or pragma compiled into the AppImage?
Seems unusable to expect the data just relative to the location of the executed binary...

[mia-0]

But that’s how it usually works—even outside AppImage usage. Think of relocating a program to a different prefix.

[probonopd]

If you use QCoreApplication::applicationDirPath() then it will work for all Linux builds, regardless of whether it is for an AppImage or not.

Based from QCoreApplication::applicationDirPath() you can of course add a relative path for the shared data of the program, e.g., assuming that the application is in bin, it could be something like (pseudeo-code!) QCoreApplication::applicationDirPath() (operator) ../share/mandebulber2.

[ghost]

In my opinion, reworking the share data folder to relative path improves portability of the system, increasing quality. @buddhi you are designer, what are your thoughts?

[zebastian]

I just read into the topic of AppImages, nice solution to get "batteries included" binaries. This will be great to incorporate in our travis file!

The relative directory solution is IMHO error prone to use for all linux compiling.
In general it should be /usr/bin/[application] and /usr/share/[application]/stuff, but the binary may be located somewhere else, maybe /usr/local/bin/[application] which will break with the relative approach.

How about we introduce a new pragma to the code (SHARED_DIR_IS_APP_DIR)? When this is set (when compiling for AppImage we can give it as a CLI argument) we will use the relative approach, otherwise we will use the default behaviour.

[ghost]

I like the idea of a pragmatic, but is it required to select one or the other alternative? Can we support both alternatives with the same binary?

is it possible to scan for shared files in multiple locations, then support both relative and standardized locals?

[probonopd]

Sure: check the path(s) relative to the application first, and if they don't exist, fall back to hardcoded absolute paths.

[buddhi1980]

@probonopd , this solution need many changes in the code. It's is good idea and doable, but now I have another priorities (OpenCL)

For short therm solution I like proposal of @zebastian to define new makro SHARED_DIR_IS_APP_DIR which could do the same as for WIN32
(systemData.sharedDir = QDir::toNativeSeparators(QDir::currentPath() + QDir::separator());)

[zebastian]

@buddhi1980 @probonopd just added a commit, which enables the pragma: e1ba399
@probonopd When you now compile with -DSHARED_DIR_IS_APP_DIR you should be able to package with AppImages. Please let me know, if you run into any problems.

Thanks for your engagement!

[probonopd]

@lachs0r can you add that to your OBS appimage.yml please?

[mia-0]

On 2017 M07 25, Tue 19:17:08 CEST probonopd wrote: @lachs0r can you add that to your OBS appimage.yml please?

Done.

[mia-0]

Except I forgot to update the package to use git master. Fixing.

[zebastian]

I just tried the installation from here:
https://software.opensuse.org//download.html?project=home%3Alachs0r%3Amandelbulber2&package=mandelbulber2
which ran fine, when i then try to execute mandelbulber i get the following issue:

mandelbulber2: /usr/lib/x86_64-linux-gnu/libQt5Multimedia.so.5: version `Qt_5' not found (required by mandelbulber2)
mandelbulber2: /usr/lib/x86_64-linux-gnu/libQt5Test.so.5: version `Qt_5' not found (required by mandelbulber2)
mandelbulber2: /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5: version `Qt_5' not found (required by mandelbulber2)
mandelbulber2: /usr/lib/x86_64-linux-gnu/libQt5Network.so.5: version `Qt_5' not found (required by mandelbulber2)
mandelbulber2: /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5: version `Qt_5' not found (required by mandelbulber2)
mandelbulber2: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5.7' not found (required by mandelbulber2)
mandelbulber2: /usr/lib/x86_64-linux-gnu/libQt5Core.so.5: version `Qt_5' not found (required by mandelbulber2)

I am still running 16.04, which may cause this, but i think this comes due to unreferenced dependencies. Anyway i am just upgrading the OS and will retry after completion.

[probonopd]

@zebastian please try the AppImage, it bundles the required subset of Qt and should therefore run on your system.

[zebastian]

@probonopd thanks, appimage runs.
Only thing missing are a couple of icons, which are part of the theme (but these are also bundled as a fallback for windows)

[probonopd]

Can you please post a screenshot? Thanks @zebastian

[mia-0]

Might have to add an icon theme to the ingredients then.

Also, we’re getting build failures on newer distros:

[   89s] /home/abuild/rpmbuild/BUILD/mandelbulber2-2.12alpha5+20170725.g4e35c973/mandelbulber2/src/test.hpp:50:82: error: could not convert 'false' from 'bool' to 'QString'
[   89s]   Test(enumTestMode _testMode, int _difficulty = 10, QString _exampleOutputPath = false)
[   89s]                                                                                   ^~~~~
[   90s] /home/abuild/rpmbuild/BUILD/mandelbulber2-2.12alpha5+20170725.g4e35c973/mandelbulber2/src/command_line_interface.cpp: In member function 'void cCommandLineInterface::runTestCasesAndExit() const':
[   90s] /home/abuild/rpmbuild/BUILD/mandelbulber2-2.12alpha5+20170725.g4e35c973/mandelbulber2/src/command_line_interface.cpp:522:32: error: could not convert 'false' from 'bool' to 'QString'
[   90s]   Test test(Test::simpleTestMode);
[   90s]                                 ^

[zebastian]

Sure, some missing locations marked in red:

@lachs0r I just introduced an issue, which i solved with the latest commit, should be compilable now with latest master

[zebastian]

@lachs0r Can you fix the icon issue? Do you need something from us to fix this?

[mia-0]

See AppImageCommunity/pkg2appimage#88. Qt is unable to select the correct theme, hence you don’t see any theme icons. There’s a workaround though (packaging Oxygen icons and moving them to the “hicolor” icon theme directory, which is the default fallback). Latest AppImages should “work”.

[zebastian]

thanks, looks good now.
But I dont understand, why there are missing in the first place. In windows there is no matching theme either, this is why we have all used tango items bundled with the application and use these svg icons as a fallbak for each icon usage, see here for example: https://github.com/buddhi1980/mandelbulber2/blob/master/mandelbulber2/qt/dock_queue.ui#L47
I would have thought, if the application cannot determine the icons for the correct theme it would always fallback to these icons.

[ghost]

@lachs0r @zebastian
I remember icons were broken in windows build for a minute.
Had to include $(QtDir)\plugins\iconengines
Hope this helps!
https://github.com/buddhi1980/mandelbulber2/blob/master/mandelbulber2/msvc/mandelbulber2_autogen.vcxproj#L321

[buddhi1980]

It was missing only in msvc build. In mingw build it was already included.

[ghost]

sounds right, btw msvc build needs updated to 2017.
still working on gsl nuget for 2017

[ghost]

Hi lachs0r, (or anyone)
I Installed mandelbulber2_2.12alpha61 from the OpenSuse Ubuntu page. When I check 'About Mandelbulber' it says 'Mandelbulber 2.11'. I saw the same thing when I compiled from source so it's not the package build. The 2.12 version has OpenCL so I'm happy with that and this is not a bug.
Anyone else seeing this inherited version number?

[buddhi1980]

Internal version number was changed in 2.12 alpha7. It's still version for developers and testers so many things can be wrong.