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

Add AppImage support to Linux builds #3688

Merged
merged 60 commits into from Oct 16, 2017

Conversation

Projects
@tresf
Member

tresf commented Jul 7, 2017

Help us test this on your OS:

  • Download a test .AppImage here:
    https://lmms.io/download/
  • Make executable and run:
    cd ~/Downloads
    chmod +x *.AppImage
    ./lmms-1.2.0-rc5-linux-x86_64.AppImage

This Pull Request will create an .AppImage installer in the build directory. Closes #3558 .

Developer Usage: make install && make appimage

Todo:

  • Remove the manual build instructions for linuxdeployqt, crosslink to a wiki or something.
  • (Upstream, not critical) Specify explicit .AppImage DESTINATION ; avoid wildcard (probonopd/linuxdeployqt#146) Update: Not needed if using appimagetool.
  • RemoteZynAddSubFX can't be linked to by lmms and when it is, it can't find Qt (d4fe98a, 8bea395)
  • The icon isn't working. Not sure what I'm missing there. (62a57ff)
  • Registering LMMS and associating its files isn't yet tested and needs some work.
  • Prevent base CMAKE_INSTALL_PREFIX (e.g. /usr) from being used (#3688 (comment)) (bf9d74b
  • Add documentation to wiki (https://github.com/LMMS/lmms/wiki/Compiling#linux-packaging)
  • Fix applications menu icon (803b3a0)
  • Optionally add QT_AUTO_SCREEN_SCALE_FACTOR=1 to fix screen scaling (Qt 5.6+) (8bc9e9d, not in rc3.89 build though)
  • (Upstream, not critical) Install mimetype icon (partially via eb5e819, appimaged isn't working yet with it Invalid/upstream bug: AppImage/AppImageKit#430)
  • Fix Jack support (ee7b988, 064beb5)
  • VSTs fail to open on Ubuntu 17.04 using wine-staging (0fed492)
  • stk/rawwaves missing from install, breaks Mallets instrument (0382b69)
  • ZynAddSubFX instrument shows blank bank. (possible duplicate of #1001) Moved to #3886
  • Investigate adding Carla to the build Out of scope. Done anyway in RC4.117. :)
  • Travis-CI to use latest Qt5 version: Moved to #3885.
     sudo add-apt-repository ppa:beineri/opt-qt58-trusty -y #qt58
     sudo apt-get update
     sudo apt-get install qt58base qt58translations qt58tools
     unset QTDIR QT_PLUGIN_PATH LD_LIBRARY_PATH
     source /opt/qt58/bin/qt58-env.sh
     cmake .. -DCMAKE_INSTALL_PREFIX=../target -DWANT_QT5=True

screen shot 2017-07-10 at 11 04 45 pm

image

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 7, 2017

Where can the resulting AppImage built by Travis CI be downloaded?

probonopd commented Jul 7, 2017

Where can the resulting AppImage built by Travis CI be downloaded?

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 7, 2017

Member

Where can the resulting AppImage built by Travis CI be downloaded?

So far, we haven't integrated this into Travis-CI yet (and we only upload our stable releases currently). I'd probably defer that task to @lukas-w once we have the portable installation working properly.

The primary purpose of this PR is to make the AppImage available to developers to create and test to get the kinks with the software worked out.

Member

tresf commented Jul 7, 2017

Where can the resulting AppImage built by Travis CI be downloaded?

So far, we haven't integrated this into Travis-CI yet (and we only upload our stable releases currently). I'd probably defer that task to @lukas-w once we have the portable installation working properly.

The primary purpose of this PR is to make the AppImage available to developers to create and test to get the kinks with the software worked out.

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

Hi @tresf how would developers test this if it cannot be downloaded? In my AppImage generation scripts, I use http://transfer.sh to get "out" the build products from Travis CI by uploading them to a temporary location where they will be available for 14 days.

probonopd commented Jul 8, 2017

Hi @tresf how would developers test this if it cannot be downloaded? In my AppImage generation scripts, I use http://transfer.sh to get "out" the build products from Travis CI by uploading them to a temporary location where they will be available for 14 days.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

how would developers test this if it cannot be downloaded?

Those interested (which tend to be very few) would compile the code, like any other feature. The temporary upload is a nice feature. I generally do something similar but manually when I need testers and which doesn't add additional logic to Travis-CI that would later have to be pulled out just prior to merge.

We should consider uploading all PRs to a temporary location as you've suggested. It'll be a welcome addition as we ramp up for nightly builds.

Member

tresf commented Jul 8, 2017

how would developers test this if it cannot be downloaded?

Those interested (which tend to be very few) would compile the code, like any other feature. The temporary upload is a nice feature. I generally do something similar but manually when I need testers and which doesn't add additional logic to Travis-CI that would later have to be pulled out just prior to merge.

We should consider uploading all PRs to a temporary location as you've suggested. It'll be a welcome addition as we ramp up for nightly builds.

@probonopd

Please see my comments, I hope these are helpful.

Show outdated Hide outdated cmake/linux/package_linux.sh.in
Show outdated Hide outdated cmake/linux/package_linux.sh.in
Show outdated Hide outdated cmake/linux/package_linux.sh.in
Show outdated Hide outdated cmake/linux/package_linux.sh.in
Show outdated Hide outdated cmake/linux/package_linux.sh.in
Show outdated Hide outdated cmake/linux/package_linux.sh.in
@@ -0,0 +1,95 @@
#!/usr/bin/env bash
# Creates Linux ".AppImage" for @PROJECT_NAME_UCASE@

This comment has been minimized.

@probonopd

probonopd Jul 8, 2017

Why are you going through all the hassle of making this part of CMake when a few lines of .travis.yml or shell script would do? Just curious. Do you think it would be possible/advantageous to have a generic CMake AppImage module/plugin? If so, would you know where to start?

@probonopd

probonopd Jul 8, 2017

Why are you going through all the hassle of making this part of CMake when a few lines of .travis.yml or shell script would do? Just curious. Do you think it would be possible/advantageous to have a generic CMake AppImage module/plugin? If so, would you know where to start?

This comment has been minimized.

@tresf

tresf Jul 8, 2017

Member

Why are you going through all the hassle of making this part of CMake when a few lines of .travis.yml or shell script would do?

I hope I explained this (same?) question properly in #3688 (comment).

Do you think it would be possible/advantageous to have a generic CMake AppImage module/plugin? If so, would you know where to start?

Hesitant "yes" to "advantageous ... cmake module" question.

A "no" to knowing where to start. The first that comes to mind is CMake's NSIS integration, but it's really ugly to use.

CMake also offers CPackDMG for Mac, but it wasn't really useful for us. Our project requires macdeployqt combined with manual relinking. So from my perspective it's much easier to test, troubleshoot and patch in a common scripting language (which is bash for the time being)

@tresf

tresf Jul 8, 2017

Member

Why are you going through all the hassle of making this part of CMake when a few lines of .travis.yml or shell script would do?

I hope I explained this (same?) question properly in #3688 (comment).

Do you think it would be possible/advantageous to have a generic CMake AppImage module/plugin? If so, would you know where to start?

Hesitant "yes" to "advantageous ... cmake module" question.

A "no" to knowing where to start. The first that comes to mind is CMake's NSIS integration, but it's really ugly to use.

CMake also offers CPackDMG for Mac, but it wasn't really useful for us. Our project requires macdeployqt combined with manual relinking. So from my perspective it's much easier to test, troubleshoot and patch in a common scripting language (which is bash for the time being)

Show outdated Hide outdated cmake/linux/package_linux.sh.in
@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

I'd like to look into the issues stated above. But for that I need the build artifacts...

The package should be identical to this. I've simply mirrored the steps outlined in #3558 and chain them into a post-cmake-install step, which is (mostly) how we package for the other platforms. Windows has direct make package integration, so that's a bit more integrated.

I'll see if I can add the build artifacts through Travis-CI. We normally don't override the CMAKE_INSTALL_PREFIX or DESTDIR parameter, so I was intending on tackling this as a separate step (something more permanent with our release process).

Member

tresf commented Jul 8, 2017

I'd like to look into the issues stated above. But for that I need the build artifacts...

The package should be identical to this. I've simply mirrored the steps outlined in #3558 and chain them into a post-cmake-install step, which is (mostly) how we package for the other platforms. Windows has direct make package integration, so that's a bit more integrated.

I'll see if I can add the build artifacts through Travis-CI. We normally don't override the CMAKE_INSTALL_PREFIX or DESTDIR parameter, so I was intending on tackling this as a separate step (something more permanent with our release process).

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

Please describe exactly what you need with regard to CMAKE_INSTALL_PREFIX and DESTDIR and I will think about a solution.

probonopd commented Jul 8, 2017

Please describe exactly what you need with regard to CMAKE_INSTALL_PREFIX and DESTDIR and I will think about a solution.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

Please describe exactly what you need with regard to CMAKE_INSTALL_PREFIX and DESTDIR and I will think about a solution.

Well, ideally we'd never want to pass install parameters directly to the make command as then our build toolchain doesn't know about it.

Our current build process simply states to the developer that if they want to install to a non-standard location, they can provide it as CMAKE_INSTALL_PREFIX. This is how we do sandboxed installs now, such as when the developer need to install, but doesn't want to do it to system space. I tried like hell to get this working with linuxdeployqt, but I couldn't get anything to work unless it was exactly /usr (something you helped me with in #3558 (comment)) which means something like DESTDIR is needed to put it back into user space. At least that's the impression I had in #3558. Open to alternatives. :)

This all may seem like overkill when something like Travis-CI can install the app to system space and then bundle it all up nicely, but Travis-CI is essentially a temporary sandbox, where our workstations aren't. As one of the primary package maintainers, I need the process to occur 100% in user space, even if Travis-CI won't necessarily benefit from it. Edit: macdeployqt works ok like this.

Does that help?

Member

tresf commented Jul 8, 2017

Please describe exactly what you need with regard to CMAKE_INSTALL_PREFIX and DESTDIR and I will think about a solution.

Well, ideally we'd never want to pass install parameters directly to the make command as then our build toolchain doesn't know about it.

Our current build process simply states to the developer that if they want to install to a non-standard location, they can provide it as CMAKE_INSTALL_PREFIX. This is how we do sandboxed installs now, such as when the developer need to install, but doesn't want to do it to system space. I tried like hell to get this working with linuxdeployqt, but I couldn't get anything to work unless it was exactly /usr (something you helped me with in #3558 (comment)) which means something like DESTDIR is needed to put it back into user space. At least that's the impression I had in #3558. Open to alternatives. :)

This all may seem like overkill when something like Travis-CI can install the app to system space and then bundle it all up nicely, but Travis-CI is essentially a temporary sandbox, where our workstations aren't. As one of the primary package maintainers, I need the process to occur 100% in user space, even if Travis-CI won't necessarily benefit from it. Edit: macdeployqt works ok like this.

Does that help?

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

Since linuxdeployqt not only bundles libraries but also resources like icons, desktop files, mime types and so on, we need a FHS-like tree somewhere with directories like bin/, lib/, share/icons/..., share/applications/*desktop, and so on. Where does not matter (as long as it is not /).

Can you provide such a tree in some (=whatever) writeable location to run linudeployqt on without much hassle? It does not have to be named $APPDIR/usr but can be named however you like. Just keep in mind that the parent directory of that directory should contain nothing else, as that is the location where AppRun will get put.

probonopd commented Jul 8, 2017

Since linuxdeployqt not only bundles libraries but also resources like icons, desktop files, mime types and so on, we need a FHS-like tree somewhere with directories like bin/, lib/, share/icons/..., share/applications/*desktop, and so on. Where does not matter (as long as it is not /).

Can you provide such a tree in some (=whatever) writeable location to run linudeployqt on without much hassle? It does not have to be named $APPDIR/usr but can be named however you like. Just keep in mind that the parent directory of that directory should contain nothing else, as that is the location where AppRun will get put.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

Can you provide such a tree in some (=whatever) writeable location to run linudeployqt on without much hassle? It does not have to be named $APPDIR/usr but can be named however you like. Just keep in mind that the parent directory of that directory should contain nothing else, as that is the location where AppRun will get put.

By default, this is how we do it, but the tool didn't work when I called it against /bin/lmms (or more properly ~/lmms/target/bin/lmms). Will the behavior differ when the desktop file is used instead of the binary?

as long as it is not /

I'm not sure what this means.

Member

tresf commented Jul 8, 2017

Can you provide such a tree in some (=whatever) writeable location to run linudeployqt on without much hassle? It does not have to be named $APPDIR/usr but can be named however you like. Just keep in mind that the parent directory of that directory should contain nothing else, as that is the location where AppRun will get put.

By default, this is how we do it, but the tool didn't work when I called it against /bin/lmms (or more properly ~/lmms/target/bin/lmms). Will the behavior differ when the desktop file is used instead of the binary?

as long as it is not /

I'm not sure what this means.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

Ok... backtracking a bit... I'm re-reading our Gitter conversation from May...

I guess my question after re-reading all of this is, what is LHS (FHS?) and how do I tell it to stop assuming everything is in usr/ ?

Conversation quoted below.

@tresf wrote:

I'm getting started with linuxdeployqt. I may be reading the documenting incorrectly but I have a few beginner questions. ​
First, where does the AppDir go when the command is called? ​
Second, what is the purpose of the travis scripts all calling unset QTDIR; ...? ​
The first time I ran the command it just exited, no errors. The second time I specifically asked it to bundle non-qt dependencies but it gave an error about a missing library. ​
... and finally... is AppImageKit required to produce an AppImage? I see the separate repo, but I'm not sure if a separate download is needed.

@probonopd wrote:

please check out the .travis.yml files in the sample projects linked in the README
it does not matter where the AppDir is when you invoke linuxdeployqt
As long as you provide it with a path to the main executable binary or even better the desktop file
You should be able to replicate the commands from the example .travis.yml in the README

@tresf wrote:

@probonopd thanks. I'm starting from scratch. I'm not writing a travis recipe just yet, I'd like to get to know the tools on CLI first.
When I make a CMAKE install inside e.g. Foo.AppDir, and then run linuxdeployqt ..>
/Foo.AppDir/bin/foo, it places the AppRun inside <src> instead of inside Foo.AppDir. I think I'm following the instructions properly.

@tresf wrote:

According to the wiki, I think I'm a directory off. The wiki says

MyApp.AppDir/
MyApp.AppDir/AppRun
MyApp.AppDir/usr/bin/myapp

I'll install to <src>/usr instead and move that inside MyApp.AppDir
One part of the tutorial references DESTDIR whereas another references INSTALL_ROOT Are they the same?

@tresf wrote:

Prefix did the trick. Now off to testing.

@probonopd wrote:

linuxdeployqt has a normal mode and a LHS-like mode. In the latter, it assumes the PREFIX inside the AppDir to be usr, i.e., the main binary resides in Your.AppDir/usr/bin/yourbinary
in the normal, non-FHS-like mode, you put the binary directly into Your.AppDir/yourbinary

Member

tresf commented Jul 8, 2017

Ok... backtracking a bit... I'm re-reading our Gitter conversation from May...

I guess my question after re-reading all of this is, what is LHS (FHS?) and how do I tell it to stop assuming everything is in usr/ ?

Conversation quoted below.

@tresf wrote:

I'm getting started with linuxdeployqt. I may be reading the documenting incorrectly but I have a few beginner questions. ​
First, where does the AppDir go when the command is called? ​
Second, what is the purpose of the travis scripts all calling unset QTDIR; ...? ​
The first time I ran the command it just exited, no errors. The second time I specifically asked it to bundle non-qt dependencies but it gave an error about a missing library. ​
... and finally... is AppImageKit required to produce an AppImage? I see the separate repo, but I'm not sure if a separate download is needed.

@probonopd wrote:

please check out the .travis.yml files in the sample projects linked in the README
it does not matter where the AppDir is when you invoke linuxdeployqt
As long as you provide it with a path to the main executable binary or even better the desktop file
You should be able to replicate the commands from the example .travis.yml in the README

@tresf wrote:

@probonopd thanks. I'm starting from scratch. I'm not writing a travis recipe just yet, I'd like to get to know the tools on CLI first.
When I make a CMAKE install inside e.g. Foo.AppDir, and then run linuxdeployqt ..>
/Foo.AppDir/bin/foo, it places the AppRun inside <src> instead of inside Foo.AppDir. I think I'm following the instructions properly.

@tresf wrote:

According to the wiki, I think I'm a directory off. The wiki says

MyApp.AppDir/
MyApp.AppDir/AppRun
MyApp.AppDir/usr/bin/myapp

I'll install to <src>/usr instead and move that inside MyApp.AppDir
One part of the tutorial references DESTDIR whereas another references INSTALL_ROOT Are they the same?

@tresf wrote:

Prefix did the trick. Now off to testing.

@probonopd wrote:

linuxdeployqt has a normal mode and a LHS-like mode. In the latter, it assumes the PREFIX inside the AppDir to be usr, i.e., the main binary resides in Your.AppDir/usr/bin/yourbinary
in the normal, non-FHS-like mode, you put the binary directly into Your.AppDir/yourbinary

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

~/lmms/target/bin/lmms should work fine, if you invoke linuxdeployqt against ~/lmms/target/share/applications/lmms.desktop. In this case, AppRun will become placed in ~/lmms and the AppImage will end up in ~. It should work, but the resulting AppImage has files in target/share rather than usr/share which violates the FHS conventions, and the optional appimaged daemon will be unable to integrate icons, mime types and menu entries into the system because it is looking for these in usr/share. Also, the binaries that are in target/bin will not end up on the $PATH when the AppImage is executed.

probonopd commented Jul 8, 2017

~/lmms/target/bin/lmms should work fine, if you invoke linuxdeployqt against ~/lmms/target/share/applications/lmms.desktop. In this case, AppRun will become placed in ~/lmms and the AppImage will end up in ~. It should work, but the resulting AppImage has files in target/share rather than usr/share which violates the FHS conventions, and the optional appimaged daemon will be unable to integrate icons, mime types and menu entries into the system because it is looking for these in usr/share. Also, the binaries that are in target/bin will not end up on the $PATH when the AppImage is executed.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

Right, these are the points made in my very first conversation. I would not consider these "fine". :)

There are still several unanswered questions. If they're not answered I'll assume the previous assumptions were and continue to be true.

Member

tresf commented Jul 8, 2017

Right, these are the points made in my very first conversation. I would not consider these "fine". :)

There are still several unanswered questions. If they're not answered I'll assume the previous assumptions were and continue to be true.

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

  1. linuxdeployqt has some unorthorox rules, the worst of them being installation must be prefixed by /usr

As discussed above, it is not a linuxdeployqt restriction but the optional appimaged daemon assumes that the content of an AppImage follows a FHS-like usr/ tree,

This means our standard build, target directories can't be used, but instead some custom commands must be used.

Alternatively, copy your tree prior to executing linudeployqt:

mkdir -p LMMS.AppDir/usr
cp -r ~/lmms/target/* LMMS.AppDir/usr/
  1. Since DESTDIR isn't provided until build time, cmake knows nothing about it. This is bad!

As per 2., you don't need to use it.

  1. RemoteZynAddSubFX is temporarily broken until we can find a way to fix linking on that.

Did you try putting it into usr/bin in the AppDir? If that works, then we can go from there.

  1. The icon isn't working. Not sure what I'm missing there.

See AppImage/AppImageKit#346.

  1. Registering LMMS and associating its files isn't yet tested and needs some work.

Did you install the optional appimaged daemon? As long as the files are in their usual places under usr/share/..., the optional appimaged daemon should register and unregister them with the system without additional work to be done on your side.

probonopd commented Jul 8, 2017

  1. linuxdeployqt has some unorthorox rules, the worst of them being installation must be prefixed by /usr

As discussed above, it is not a linuxdeployqt restriction but the optional appimaged daemon assumes that the content of an AppImage follows a FHS-like usr/ tree,

This means our standard build, target directories can't be used, but instead some custom commands must be used.

Alternatively, copy your tree prior to executing linudeployqt:

mkdir -p LMMS.AppDir/usr
cp -r ~/lmms/target/* LMMS.AppDir/usr/
  1. Since DESTDIR isn't provided until build time, cmake knows nothing about it. This is bad!

As per 2., you don't need to use it.

  1. RemoteZynAddSubFX is temporarily broken until we can find a way to fix linking on that.

Did you try putting it into usr/bin in the AppDir? If that works, then we can go from there.

  1. The icon isn't working. Not sure what I'm missing there.

See AppImage/AppImageKit#346.

  1. Registering LMMS and associating its files isn't yet tested and needs some work.

Did you install the optional appimaged daemon? As long as the files are in their usual places under usr/share/..., the optional appimaged daemon should register and unregister them with the system without additional work to be done on your side.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

copy your tree prior to executing linudeployqt

If this works, that would remove DESTDIR and settle it. I'll take a swing at it that way, thanks!

Member

tresf commented Jul 8, 2017

copy your tree prior to executing linudeployqt

If this works, that would remove DESTDIR and settle it. I'll take a swing at it that way, thanks!

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

As long as the files are in their usual places under usr/share/..., the optional appimaged daemon should register and unregister them with the system without additional work to be done on your side.

That's great news as well, thanks.

Member

tresf commented Jul 8, 2017

As long as the files are in their usual places under usr/share/..., the optional appimaged daemon should register and unregister them with the system without additional work to be done on your side.

That's great news as well, thanks.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

@probonopd What about this question...

I can't yet find a way to specify the DESTINATION parameter. Perhaps @probonopd can shed some light. I'm pretty sure shellcheck won't like the *.AppImage command.

Member

tresf commented Jul 8, 2017

@probonopd What about this question...

I can't yet find a way to specify the DESTINATION parameter. Perhaps @probonopd can shed some light. I'm pretty sure shellcheck won't like the *.AppImage command.

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

Updates...

  1. The machine I'm on today is i386, so I had to fix the download link to assume architecture. This should be quite obvious if someone's trying on i386 or arm. I've also included quick build instructions. Logic could be better, but it should do the trick for now. 91a000b#diff-5b07d65c1f1bdd29f324c363c12c9c9bR19

  2. Our desktop file uses Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lmms %f but it seems to confuse linuxdeployqt. I've written a workaround to create a temporary .desktop file that is compatible with linuxdeployqt. I'd be happy to file an upstream bug report for this if needed. The error was:

    ERROR: Could not determine the path to the executable based on the desktop file
    
  3. Now I'm stuck. linuxdeployqt finds the desktop file and icon, but this happens:

    Desktop file as first argument: "/home/tres/lmms/build/LMMS.AppDir/usr/share/applications/lmms.desktop" 
    desktopExecEntry: "lmms" 
    desktopIconEntry: "lmms" 
    Found binary from desktop file: "/home/tres/lmms/build/LMMS.AppDir/usr/bin/lmms" 
    FHS-like mode with PREFIX, fhsPrefix: "/home/tres/lmms/build/LMMS.AppDir/usr" 
    app-binary: "/home/tres/lmms/build/LMMS.AppDir/usr/bin/lmms" 
    appDirPath: "/home/tres/lmms/build/LMMS.AppDir" 
    relativeBinPath: "usr/bin/lmms" 
    Copied "/home/tres/lmms/build/LMMS.AppDir/usr/share/applications/lmms.desktop" to    "/home/tres/lmms/build/LMMS.AppDir/lmms.desktop" 
    Found icons from desktop file:("/home/tres/lmms/build/LMMS.AppDir/usr/share/pixmaps/lmms.png", "/home/tres/lmms/build/LMMS.AppDir/usr/share/lmms/backgrounds/lmms_tile.png") 
    ERROR: Could not start patchelf tool. Process error is "Not a directory" 
    make[3]: *** [cmake/linux/CMakeFiles/appimage] Error 1
    make[2]: *** [cmake/linux/CMakeFiles/appimage.dir/all] Error 2
    make[1]: *** [cmake/linux/CMakeFiles/appimage.dir/rule] Error 2
    make: *** [appimage] Error 2
    
Member

tresf commented Jul 8, 2017

Updates...

  1. The machine I'm on today is i386, so I had to fix the download link to assume architecture. This should be quite obvious if someone's trying on i386 or arm. I've also included quick build instructions. Logic could be better, but it should do the trick for now. 91a000b#diff-5b07d65c1f1bdd29f324c363c12c9c9bR19

  2. Our desktop file uses Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lmms %f but it seems to confuse linuxdeployqt. I've written a workaround to create a temporary .desktop file that is compatible with linuxdeployqt. I'd be happy to file an upstream bug report for this if needed. The error was:

    ERROR: Could not determine the path to the executable based on the desktop file
    
  3. Now I'm stuck. linuxdeployqt finds the desktop file and icon, but this happens:

    Desktop file as first argument: "/home/tres/lmms/build/LMMS.AppDir/usr/share/applications/lmms.desktop" 
    desktopExecEntry: "lmms" 
    desktopIconEntry: "lmms" 
    Found binary from desktop file: "/home/tres/lmms/build/LMMS.AppDir/usr/bin/lmms" 
    FHS-like mode with PREFIX, fhsPrefix: "/home/tres/lmms/build/LMMS.AppDir/usr" 
    app-binary: "/home/tres/lmms/build/LMMS.AppDir/usr/bin/lmms" 
    appDirPath: "/home/tres/lmms/build/LMMS.AppDir" 
    relativeBinPath: "usr/bin/lmms" 
    Copied "/home/tres/lmms/build/LMMS.AppDir/usr/share/applications/lmms.desktop" to    "/home/tres/lmms/build/LMMS.AppDir/lmms.desktop" 
    Found icons from desktop file:("/home/tres/lmms/build/LMMS.AppDir/usr/share/pixmaps/lmms.png", "/home/tres/lmms/build/LMMS.AppDir/usr/share/lmms/backgrounds/lmms_tile.png") 
    ERROR: Could not start patchelf tool. Process error is "Not a directory" 
    make[3]: *** [cmake/linux/CMakeFiles/appimage] Error 1
    make[2]: *** [cmake/linux/CMakeFiles/appimage.dir/all] Error 2
    make[1]: *** [cmake/linux/CMakeFiles/appimage.dir/rule] Error 2
    make: *** [appimage] Error 2
    
@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

linuxeployqt has no DESTINATION parameter. The name of the AppImage is automatically determined based on the Name= entry in the desktop file. (The message you see in the log comes from the underlying appimagetool that is being used.)

You don't need to use an *.AppImage command tough. Just replace the Asterisk with the real name, should be fine.

probonopd commented Jul 8, 2017

linuxeployqt has no DESTINATION parameter. The name of the AppImage is automatically determined based on the Name= entry in the desktop file. (The message you see in the log comes from the underlying appimagetool that is being used.)

You don't need to use an *.AppImage command tough. Just replace the Asterisk with the real name, should be fine.

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lmms %f

Not sure how to parse the payload executable from this line, and if we allow this, there might be countless other more complex ones, including bash -e ... ones. Currently we are expecting a straightforward Exec=nameofthebinary entry.

If you urgently need the QT_X11_NO_NATIVE_MENUBAR=1 environment variable, then move usr/bin/lmms to usr/bin/lmms.real and put a bash script in its place that exports the variable and launches the real executable.

But if QT_X11_NO_NATIVE_MENUBAR=1 is essentially needed for everyone, why not hardcode it in the application in the first place? Then it'd behave correctly also when launched from a command line.

probonopd commented Jul 8, 2017

Exec=env QT_X11_NO_NATIVE_MENUBAR=1 lmms %f

Not sure how to parse the payload executable from this line, and if we allow this, there might be countless other more complex ones, including bash -e ... ones. Currently we are expecting a straightforward Exec=nameofthebinary entry.

If you urgently need the QT_X11_NO_NATIVE_MENUBAR=1 environment variable, then move usr/bin/lmms to usr/bin/lmms.real and put a bash script in its place that exports the variable and launches the real executable.

But if QT_X11_NO_NATIVE_MENUBAR=1 is essentially needed for everyone, why not hardcode it in the application in the first place? Then it'd behave correctly also when launched from a command line.

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

ERROR: Could not start patchelf tool. Process error is "Not a directory"

Where did you get your linuxdeployqt from?

probonopd commented Jul 8, 2017

ERROR: Could not start patchelf tool. Process error is "Not a directory"

Where did you get your linuxdeployqt from?

probonopd added a commit to AppImage/AppImageKit that referenced this pull request Jul 8, 2017

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 8, 2017

Member

Added debug logs: https://gist.github.com/tresf/28bf36131c090a385e9fdf47e851e5c3

Where did you get your linuxdeployqt from?

I compiled it like this:

git clone https://github.com/probonopd/linuxdeployqt
cd linuxdeployqt
qmake
make
mv bin/linuxdeployqt ~/bin/

If you urgently need the QT_X11_NO_NATIVE_MENUBAR=1 environment variable, then move usr/bin/lmms to usr/bin/lmms.real and put a bash script in its place that exports the variable and launches the real executable.

Is there an order of operations that avoids a hacked solution? In the foo.real approach, our .desktop file still requires divergence from what we use today. Is there a way to get our desktop files in the right place manually and just tell linuxdeployqt to use the binary?

If not, fine. Perhaps we're allowing the application to assume too much because I'm also not opposed to separating linuxdeployqt and appimagekit. This would also allow us to bring back the requested DESTINATION parameter. On Mac, we don't use a singular tool for relinking and packaging, we separate the steps. This seems like a perfectly reasonably workflow.

But if QT_X11_NO_NATIVE_MENUBAR=1 is essentially needed for everyone, why not hardcode it in the application in the first place?

This is an environmental variable picked up by Unity. It was added per #488. It's a desktop workaround and has no place inside the C++ codebase.

Member

tresf commented Jul 8, 2017

Added debug logs: https://gist.github.com/tresf/28bf36131c090a385e9fdf47e851e5c3

Where did you get your linuxdeployqt from?

I compiled it like this:

git clone https://github.com/probonopd/linuxdeployqt
cd linuxdeployqt
qmake
make
mv bin/linuxdeployqt ~/bin/

If you urgently need the QT_X11_NO_NATIVE_MENUBAR=1 environment variable, then move usr/bin/lmms to usr/bin/lmms.real and put a bash script in its place that exports the variable and launches the real executable.

Is there an order of operations that avoids a hacked solution? In the foo.real approach, our .desktop file still requires divergence from what we use today. Is there a way to get our desktop files in the right place manually and just tell linuxdeployqt to use the binary?

If not, fine. Perhaps we're allowing the application to assume too much because I'm also not opposed to separating linuxdeployqt and appimagekit. This would also allow us to bring back the requested DESTINATION parameter. On Mac, we don't use a singular tool for relinking and packaging, we separate the steps. This seems like a perfectly reasonably workflow.

But if QT_X11_NO_NATIVE_MENUBAR=1 is essentially needed for everyone, why not hardcode it in the application in the first place?

This is an environmental variable picked up by Unity. It was added per #488. It's a desktop workaround and has no place inside the C++ codebase.

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Jul 8, 2017

I compiled it like this

Do you also have patchelf and appimagetool on your $PATH? linuxdeployqt uses them to do the actual work.

Is there an order of operations that avoids a hacked solution?

Yes:

  1. Run linuxdeployqt ... -bundle-non-qt-libs
  2. Delete the AppRun symlink, replace it by a bash script that sets the environment variable and launches your application
  3. Run appimagetool on your AppDir to produce the AppImage

Is there a way to get our desktop files in the right place manually and just tell linuxdeployqt to use the binary?

It's not just about appimagetool finding the main executable, it's also for the AppImage at runtime to find its main (payload) executable. This works as follows:

  1. User executes AppImage
  2. The AppImage gets mounted to a temporary mountpoint
  3. The file called "AppRun" in the top-level directory of the AppDir is executed (by default, linuxdeployqt puts a symlink to the payload application there, but it could also be a C executable or even a bash script)
  4. AppRun runs the payload application
  5. After AppRun exits, the AppImage gets unmounted and the mountpoint deleted

probonopd commented Jul 8, 2017

I compiled it like this

Do you also have patchelf and appimagetool on your $PATH? linuxdeployqt uses them to do the actual work.

Is there an order of operations that avoids a hacked solution?

Yes:

  1. Run linuxdeployqt ... -bundle-non-qt-libs
  2. Delete the AppRun symlink, replace it by a bash script that sets the environment variable and launches your application
  3. Run appimagetool on your AppDir to produce the AppImage

Is there a way to get our desktop files in the right place manually and just tell linuxdeployqt to use the binary?

It's not just about appimagetool finding the main executable, it's also for the AppImage at runtime to find its main (payload) executable. This works as follows:

  1. User executes AppImage
  2. The AppImage gets mounted to a temporary mountpoint
  3. The file called "AppRun" in the top-level directory of the AppDir is executed (by default, linuxdeployqt puts a symlink to the payload application there, but it could also be a C executable or even a bash script)
  4. AppRun runs the payload application
  5. After AppRun exits, the AppImage gets unmounted and the mountpoint deleted
@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Jul 9, 2017

Member

Do you also have patchelf and appimagetool on your $PATH?

Thanks that got it working on i686. 👍

It's not just about appimagetool finding the main executable, it's also for the AppImage at runtime to find its main (payload) executable.

That makes perfect sense. Ok... I'll see what I can hack together. I'd prefer if we didn't have to hardcode this in two separate places so I'll have to think about it a bit more in regards to how to wrap it into the portable image. It's a minor inconvenience, so it's certainly not a show stopper.

Member

tresf commented Jul 9, 2017

Do you also have patchelf and appimagetool on your $PATH?

Thanks that got it working on i686. 👍

It's not just about appimagetool finding the main executable, it's also for the AppImage at runtime to find its main (payload) executable.

That makes perfect sense. Ok... I'll see what I can hack together. I'd prefer if we didn't have to hardcode this in two separate places so I'll have to think about it a bit more in regards to how to wrap it into the portable image. It's a minor inconvenience, so it's certainly not a show stopper.

@PhysSong PhysSong moved this from Done to To Do in Release LMMS 1.2.0-RC5 Oct 17, 2017

@PhysSong PhysSong moved this from To Do to Done in Release LMMS 1.2.0-RC5 Oct 17, 2017

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 13, 2017

Thank you very much.
Please, don't forget to update it =)
It's brilliant !

vlad1777d commented Nov 13, 2017

Thank you very much.
Please, don't forget to update it =)
It's brilliant !

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Nov 13, 2017

Member

Please, don't forget to update it =)

I've refreshed the link with some fixes to the jack implementation. We'll be providing these as official builds on our downloads page when 1.2.0 is official released.

https://github.com/tresf/lmms/releases/download/v1.2.0-rc4/lmms-1.2.0-rc4.96-linux-x86_64.AppImage

Member

tresf commented Nov 13, 2017

Please, don't forget to update it =)

I've refreshed the link with some fixes to the jack implementation. We'll be providing these as official builds on our downloads page when 1.2.0 is official released.

https://github.com/tresf/lmms/releases/download/v1.2.0-rc4/lmms-1.2.0-rc4.96-linux-x86_64.AppImage

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 15, 2017

I don't know where is better to write, but can I somehow add Carla to the appimage build ?
My system version of LMMS (1.1.3) has Carla Rack, Carla Patchbay in the list of instruments.
Also, I installed standalone Carla packages. But RC4 doesn't have Carla.
I open .sfz libraries with it.
screenshot from 2017-11-16 00-14-35
screenshot from 2017-11-16 00-14-58

vlad1777d commented Nov 15, 2017

I don't know where is better to write, but can I somehow add Carla to the appimage build ?
My system version of LMMS (1.1.3) has Carla Rack, Carla Patchbay in the list of instruments.
Also, I installed standalone Carla packages. But RC4 doesn't have Carla.
I open .sfz libraries with it.
screenshot from 2017-11-16 00-14-35
screenshot from 2017-11-16 00-14-58

@tresf

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Nov 15, 2017

Member

@vlad1777d probably a separate bug report would be the place. I don't know how portable Carla is and I also don't know what happens if we build with system (non-portable) support for it and it's missing. I recommend tagging @falkTX -- the Carla author -- in the new bug report. We can offer this for stable-1.2 fairly sanely since it's not a new feature, just working out the bugs of packaging another dependency.

For starters, you can try to use make install && make appimage on a build that has Carla enabled and see how far you get. Note, appimages are broken due to an upstream bug here: probonopd/linuxdeployqt#184. So you'll have to hack a workaround in --
also explained in the bug report -- in order for LMMS to actually package properly. The bug is marked as high priority, so it should be fixed very soon.

Member

tresf commented Nov 15, 2017

@vlad1777d probably a separate bug report would be the place. I don't know how portable Carla is and I also don't know what happens if we build with system (non-portable) support for it and it's missing. I recommend tagging @falkTX -- the Carla author -- in the new bug report. We can offer this for stable-1.2 fairly sanely since it's not a new feature, just working out the bugs of packaging another dependency.

For starters, you can try to use make install && make appimage on a build that has Carla enabled and see how far you get. Note, appimages are broken due to an upstream bug here: probonopd/linuxdeployqt#184. So you'll have to hack a workaround in --
also explained in the bug report -- in order for LMMS to actually package properly. The bug is marked as high priority, so it should be fixed very soon.

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 15, 2017

Thanks, @tresf , I created new bugreport and tagged you there. If I wrote something wrong or didn't tell something - correct my message.

vlad1777d commented Nov 15, 2017

Thanks, @tresf , I created new bugreport and tagged you there. If I wrote something wrong or didn't tell something - correct my message.

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 19, 2017

Hello @tresf .
This appimage loads near 2 minutes, it's normal ?
(lmms-1.2.0-rc4.96-linux-x86_64.AppImage)

Here is it's ourput:

'/home/vlad/Programs/audio/lmms-1.2.0-rc4.96-linux-x86_64.AppImage' 
Jack appears to be installed on this system, so we'll use it.
Notice: could not set realtime priority.
VST sync support disabled in your configuration
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/5)(1: Operation not permitted)
JackClient::AcquireSelfRealTime error

vlad1777d commented Nov 19, 2017

Hello @tresf .
This appimage loads near 2 minutes, it's normal ?
(lmms-1.2.0-rc4.96-linux-x86_64.AppImage)

Here is it's ourput:

'/home/vlad/Programs/audio/lmms-1.2.0-rc4.96-linux-x86_64.AppImage' 
Jack appears to be installed on this system, so we'll use it.
Notice: could not set realtime priority.
VST sync support disabled in your configuration
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/5)(1: Operation not permitted)
JackClient::AcquireSelfRealTime error
@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Nov 19, 2017

To find out whether AppImage is at fault here, please extract the AppImage with ./Your.AppImage --appimage-extract, and then run ./squashfs-root/AppRun to compare the performance of the AppImage vs. the unpacked version. Thanks.

probonopd commented Nov 19, 2017

To find out whether AppImage is at fault here, please extract the AppImage with ./Your.AppImage --appimage-extract, and then run ./squashfs-root/AppRun to compare the performance of the AppImage vs. the unpacked version. Thanks.

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 19, 2017

@probonopd ,
The appimage ran:

  • totally: 41 seconds,
  • the most of time took "Preparing UI": 38 seconds

Unpacked appimage ran:

  • totally: 47 seconds,
  • the most of time took "Preparing UI": 44 seconds

LMMS 1.1.3 ran:

  • totally: 3 seconds

Appimage output:

'/home/vlad/Programs/audio/lmms-1.2.0-rc4.96-linux-x86_64.AppImage' 
Jack appears to be installed on this system, so we'll use it.
Notice: could not set realtime priority.
VST sync support disabled in your configuration
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/5)(1: Operation not permitted)
JackClient::AcquireSelfRealTime error

Unpacked appimage output:

./squashfs-root/AppRun
Jack appears to be installed on this system, so we'll use it.
Notice: could not set realtime priority.
VST sync support disabled in your configuration
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/5)(1: Operation not permitted)
JackClient::AcquireSelfRealTime error

LMMS 1.1.3 output:

Notice: could not set realtime priority.
VST sync support disabled in your configuration
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/5)(1: Operation not permitted)
JackClient::AcquireSelfRealTime error

Seems, they (packed and unpacked RC4) load the same time.

Also after pressing button "Add effect" in "FX-Mixer", now left near 3.30 minutes, nothing loaded, seems, it's a freeze. I tried pressing this button several times.

For comparison, LMMS 1.1.3 loaded in 3 seconds, after pressing "Add effect" to appearing window with list of effects was spend near 1 second.

(I use standard jack installed with "aptitude install qjackctl")
Jackd version:
jackd2:
i A 1.9.10+20150825git1ed50c92~dfsg-1ubuntu1 xenial 500

System: Linux Mint 18.2 x64 Cinnamon.
CPU: Intel Core i3 540 (3.07 gHz x2, 4 threads).
GPU: Nvidia GT 630
Ram: 7.8 Gib DDR3

vlad1777d commented Nov 19, 2017

@probonopd ,
The appimage ran:

  • totally: 41 seconds,
  • the most of time took "Preparing UI": 38 seconds

Unpacked appimage ran:

  • totally: 47 seconds,
  • the most of time took "Preparing UI": 44 seconds

LMMS 1.1.3 ran:

  • totally: 3 seconds

Appimage output:

'/home/vlad/Programs/audio/lmms-1.2.0-rc4.96-linux-x86_64.AppImage' 
Jack appears to be installed on this system, so we'll use it.
Notice: could not set realtime priority.
VST sync support disabled in your configuration
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/5)(1: Operation not permitted)
JackClient::AcquireSelfRealTime error

Unpacked appimage output:

./squashfs-root/AppRun
Jack appears to be installed on this system, so we'll use it.
Notice: could not set realtime priority.
VST sync support disabled in your configuration
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/5)(1: Operation not permitted)
JackClient::AcquireSelfRealTime error

LMMS 1.1.3 output:

Notice: could not set realtime priority.
VST sync support disabled in your configuration
Cannot lock down 82274202 byte memory area (Cannot allocate memory)
Cannot use real-time scheduling (RR/5)(1: Operation not permitted)
JackClient::AcquireSelfRealTime error

Seems, they (packed and unpacked RC4) load the same time.

Also after pressing button "Add effect" in "FX-Mixer", now left near 3.30 minutes, nothing loaded, seems, it's a freeze. I tried pressing this button several times.

For comparison, LMMS 1.1.3 loaded in 3 seconds, after pressing "Add effect" to appearing window with list of effects was spend near 1 second.

(I use standard jack installed with "aptitude install qjackctl")
Jackd version:
jackd2:
i A 1.9.10+20150825git1ed50c92~dfsg-1ubuntu1 xenial 500

System: Linux Mint 18.2 x64 Cinnamon.
CPU: Intel Core i3 540 (3.07 gHz x2, 4 threads).
GPU: Nvidia GT 630
Ram: 7.8 Gib DDR3

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Nov 19, 2017

So that AppImage is actually faster than the unpacked binaries? That should rule out the AppImage itself as the root cause. I cannot say what causes the contents of the AppImage to be that slow, but I doubt it's normal.

probonopd commented Nov 19, 2017

So that AppImage is actually faster than the unpacked binaries? That should rule out the AppImage itself as the root cause. I cannot say what causes the contents of the AppImage to be that slow, but I doubt it's normal.

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 19, 2017

@probonopd , updated answer. I think that it's inaccuracy. They load near the same time (packed and unpacked), but they load in times slower than LMMS 1.1.3.
RC4.29 acts the same like RC4.96.

System: Linux Mint 18.2 x64 Cinnamon.
CPU: Intel Core i3 540 (3.07 gHz x2, 4 threads).
GPU: Nvidia GT 630
Ram: 7.8 Gib DDR3

LMMS 1.1.3 loads near 3-8 seconds,
LMMS 1.2.0 RC4.96 now ran in 80 seconds (first time, it differs sometimes)

I think it's obvious that somewhere is something wrong =)
Main is to figure out what certainly.

vlad1777d commented Nov 19, 2017

@probonopd , updated answer. I think that it's inaccuracy. They load near the same time (packed and unpacked), but they load in times slower than LMMS 1.1.3.
RC4.29 acts the same like RC4.96.

System: Linux Mint 18.2 x64 Cinnamon.
CPU: Intel Core i3 540 (3.07 gHz x2, 4 threads).
GPU: Nvidia GT 630
Ram: 7.8 Gib DDR3

LMMS 1.1.3 loads near 3-8 seconds,
LMMS 1.2.0 RC4.96 now ran in 80 seconds (first time, it differs sometimes)

I think it's obvious that somewhere is something wrong =)
Main is to figure out what certainly.

@TheAssassin

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Nov 19, 2017

@probonopd @vlad1777d running each of these cases once on some machine with unspecified specs which is also used for other stuff in the background doesn't produce meaningful results (even running 100 times won't in my opinion).

TheAssassin commented Nov 19, 2017

@probonopd @vlad1777d running each of these cases once on some machine with unspecified specs which is also used for other stuff in the background doesn't produce meaningful results (even running 100 times won't in my opinion).

@probonopd

This comment has been minimized.

Show comment
Hide comment
@probonopd

probonopd Nov 19, 2017

Yes, my only point was that I don't think the slowdown is coming from AppImage.

probonopd commented Nov 19, 2017

Yes, my only point was that I don't think the slowdown is coming from AppImage.

@TheAssassin

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Nov 19, 2017

Calling strace or using a profiler might help.

TheAssassin commented Nov 19, 2017

Calling strace or using a profiler might help.

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 19, 2017

I can do this if you tell me certain steps, because I'm not familiar with those things.

vlad1777d commented Nov 19, 2017

I can do this if you tell me certain steps, because I'm not familiar with those things.

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 19, 2017

I figured out. It was so when I turned on jack manually before launching RC4.
When I turn it off, than it loads near 3 seconds too.

(in both cases in settings "Jack" is chosen as audio driver)

But problem with long loading after pressing "Add effect" button in "FX-Mixer" is still present.

vlad1777d commented Nov 19, 2017

I figured out. It was so when I turned on jack manually before launching RC4.
When I turn it off, than it loads near 3 seconds too.

(in both cases in settings "Jack" is chosen as audio driver)

But problem with long loading after pressing "Add effect" button in "FX-Mixer" is still present.

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 19, 2017

No, that was not the matter. I figured out now a real matter.
It's because I created link in /home/username/lmms/samples to my instruments folder on other disc (there are all my instruments, it's large).

Was Jack runned manually or automatically by LMMS it doesn't matter.

But anyway, LMMS 1.1.3 runs in near 3 seconds with present link too.

I created that link not to select each time "Computer/media/username/Storm/instruments/sf2/drums/hpa_drumkit/file.sf2" when I'm trying to load instrument.

And the problem in waiting near 4 minutes after pressing "Add effect" in "FX-Mixer" is still present.

vlad1777d commented Nov 19, 2017

No, that was not the matter. I figured out now a real matter.
It's because I created link in /home/username/lmms/samples to my instruments folder on other disc (there are all my instruments, it's large).

Was Jack runned manually or automatically by LMMS it doesn't matter.

But anyway, LMMS 1.1.3 runs in near 3 seconds with present link too.

I created that link not to select each time "Computer/media/username/Storm/instruments/sf2/drums/hpa_drumkit/file.sf2" when I'm trying to load instrument.

And the problem in waiting near 4 minutes after pressing "Add effect" in "FX-Mixer" is still present.

@TheAssassin

This comment has been minimized.

Show comment
Hide comment
@TheAssassin

TheAssassin Nov 19, 2017

@vlad1777d call sudo strace LMMS*.AppImage (sudo is required here because of how the AppImage works (technical detail: it's because of FUSE)), or strace squashfs-root/AppRun for the extracted (beware, no sudo here).

TheAssassin commented Nov 19, 2017

@vlad1777d call sudo strace LMMS*.AppImage (sudo is required here because of how the AppImage works (technical detail: it's because of FUSE)), or strace squashfs-root/AppRun for the extracted (beware, no sudo here).

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 19, 2017

@TheAssassin ,
Here is strace: https://pastebin.com/Sf5xsFVj
But I don't know, is it normal that it's terminated and nothing started.

vlad1777d commented Nov 19, 2017

@TheAssassin ,
Here is strace: https://pastebin.com/Sf5xsFVj
But I don't know, is it normal that it's terminated and nothing started.

@zapashcanon

This comment has been minimized.

Show comment
Hide comment
@zapashcanon

zapashcanon Nov 19, 2017

Contributor

wait4(-1, LMMS cannot be run as root.
Use "--allowroot" to override.

Contributor

zapashcanon commented Nov 19, 2017

wait4(-1, LMMS cannot be run as root.
Use "--allowroot" to override.

@vlad1777d

This comment has been minimized.

Show comment
Hide comment
@vlad1777d

vlad1777d Nov 19, 2017

Strace: LMMS (appimage) normal launch:

Strace: LMMS (appimage) launch with link to instrumens folder in /home/user/lmms/samples:

  • https://pastebin.com/kFyiimXq
    It stacked on this line in console (onto near 1.5 minutes):
    You can render your songs and listen to the output files...
    While in spash screen was written: "Preparing UI"

Added separate bugreport about pressing "Add effect" button: #3990

vlad1777d commented Nov 19, 2017

Strace: LMMS (appimage) normal launch:

Strace: LMMS (appimage) launch with link to instrumens folder in /home/user/lmms/samples:

  • https://pastebin.com/kFyiimXq
    It stacked on this line in console (onto near 1.5 minutes):
    You can render your songs and listen to the output files...
    While in spash screen was written: "Preparing UI"

Added separate bugreport about pressing "Add effect" button: #3990

@lukas-w

This comment has been minimized.

Show comment
Hide comment
@lukas-w

lukas-w Nov 25, 2017

Member

Can we remove this flag again? Qt 5.8 falsely detects the scaling for me, rendering LMMS AppImages unusable on my system with no way to change the behaviour.

image

Member

lukas-w commented on 8bc9e9d Nov 25, 2017

Can we remove this flag again? Qt 5.8 falsely detects the scaling for me, rendering LMMS AppImages unusable on my system with no way to change the behaviour.

image

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Nov 25, 2017

Member

Perhaps we bump them to 5.9 then and solve both problems?

Member

tresf replied Nov 25, 2017

Perhaps we bump them to 5.9 then and solve both problems?

This comment has been minimized.

Show comment
Hide comment
@lukas-w

lukas-w Nov 25, 2017

Member

Not sure if 5.9 solves it, I'll test it in a minute.

Member

lukas-w replied Nov 25, 2017

Not sure if 5.9 solves it, I'll test it in a minute.

This comment has been minimized.

Show comment
Hide comment
@lukas-w

lukas-w Nov 25, 2017

Member

What do you mean by "solve both problems"?

Member

lukas-w replied Nov 25, 2017

What do you mean by "solve both problems"?

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Nov 25, 2017

Member

Your feedback from 5.9 in #3814 is what allowed merge. We can also use a conditional in the AppRun against qmake, although version parsing may be challenging inside the bash script.

Member

tresf replied Nov 25, 2017

Your feedback from 5.9 in #3814 is what allowed merge. We can also use a conditional in the AppRun against qmake, although version parsing may be challenging inside the bash script.

This comment has been minimized.

Show comment
Hide comment
@tresf
Member

tresf replied Nov 25, 2017

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Nov 27, 2017

Member

Bumped Qt to 5.9 via d0194e6.

Member

tresf replied Nov 27, 2017

Bumped Qt to 5.9 via d0194e6.

This comment has been minimized.

Show comment
Hide comment
@falkTX

falkTX Dec 1, 2017

Contributor

I am using the latest AppImage build, and can report scaling is not working correctly on my system (Ubuntu 16.04 based, using KDE5 neon)

It's a laptop with an external screen connected.
On the laptop screen, LMMS looks like this:

screenshot_20171201_122349

Now on the external screen LMMS looks like this:

screenshot_20171201_122443

I have no scaling whatsoever enabled on this system.
LMMS is unusable on both screens :(

Contributor

falkTX replied Dec 1, 2017

I am using the latest AppImage build, and can report scaling is not working correctly on my system (Ubuntu 16.04 based, using KDE5 neon)

It's a laptop with an external screen connected.
On the laptop screen, LMMS looks like this:

screenshot_20171201_122349

Now on the external screen LMMS looks like this:

screenshot_20171201_122443

I have no scaling whatsoever enabled on this system.
LMMS is unusable on both screens :(

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Dec 1, 2017

Member

We'll turn off QT_AUTO_SCREEN_SCALE_FACTOR then for now. People can always flag it back on manually. I'll add this to the Carla PR and upload a new AppImage.

Member

tresf replied Dec 1, 2017

We'll turn off QT_AUTO_SCREEN_SCALE_FACTOR then for now. People can always flag it back on manually. I'll add this to the Carla PR and upload a new AppImage.

This comment has been minimized.

Show comment
Hide comment
@tresf

tresf Dec 1, 2017

Member

AppImage link updated in #4026 with this change applied.

Member

tresf replied Dec 1, 2017

AppImage link updated in #4026 with this change applied.

@Luraktinus

This comment has been minimized.

Show comment
Hide comment
@Luraktinus

Luraktinus Jan 11, 2018

a thousand times: "THANK YOU, FINALLY I CAN JUST USE IT ON ANY DISTRO"

Luraktinus commented Jan 11, 2018

a thousand times: "THANK YOU, FINALLY I CAN JUST USE IT ON ANY DISTRO"

tresf referenced this pull request in probonopd/linuxdeployqt Oct 3, 2018

shared: Update excludelist
Signed-off-by: Patrick José Pereira <patrickelectric@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment