Ubuntu packaging

[tresf]

Better Ubuntu Packaging:

• [ ] Our information for stable-1.0 could be improved. Details noted in screenshot below
• [ ] We could use a person or process which packages this for us into the Ubuntu repositories. Israel's notes here: Packaging-Ubuntu-PPA

---

[ghost]

Another thing, WINE is a dependency...why?

[badosu]

@crank123 For VST support.

[ghost]

Wouldn't it have VST support anyway?

[badosu]

I am not particularly familiar with this part of the code, so someone more experienced can chime in.

VST's are usually dlls, which in linux means we need to simulate windows api to be able to execute them, that's where wine comes in.

I guess for windows support is native.

[tresf]

Another thing, WINE is a dependency...why?

Should be optional. At least that was always the intention. Why Wine? Because 99% of VSTs are win32. They can exist for other platforms, but almost never exist natively for Linux....

[badosu]

@tresf And even those that exist for linux we don't support, if I am not mistaken.

[tresf]

@tresf And even those [VSTs] that exist for linux we don't support, if I am not mistaken

Correct.

[diizy]

On 01/14/2015 06:23 AM, Amadeus Folego wrote:

@tresf https://github.com/tresf And even those that exist for linux we don't support, if I am not mistaken.

We do, via Carla.

Support is still experimental though, so things like automations aren't supported yet.

[diizy]

On 01/14/2015 03:35 AM, Tres Finocchiaro wrote:

They van exist for other platforms, but almost never exist natively for Linux....

That used to be true. There's actually quite a bunch of LinuxVST's these days. Not as much as win32 ones, but still.

[tresf]

So we could really use a package maintainer for the Canonical flavors. Israel was nice enough to send over his packaging cheat sheet, but I've yet to try any of it.

https://github.com/LMMS/lmms/wiki/Packaging-Ubuntu-PPA

Volunteers? @mikobuntu? @Umcaruje? :pizza:

[ghost]

Hi everyone, I have been trying to get lmms 1.1.3 into Ubuntu Wily, with the separate VST package, but we are having issues with CMake. Timo and I have been commenting about this: https://code.launchpad.net/~israeldahl/ubuntu/wily/lmms/lmms/+merge/266928

My guess is that CMake 3.3.X is not handling things correctly in Ubuntu wily. Your CMakeLists looks for: CMAKE_MINIMUM_REQUIRED(VERSION 2.4.5) So there obviously has been many changes since then. Does it work for anyone to use the latest 3.3.X version of cmake in their own environments?

The other issue we might face is the newer gcc version.....

But the errors we have found have been related to Cmake thus far.

Initially cmake could not find FLUID, even though I include the fluid binary as part of the build depends (in the debian packaging) and it does exist in the build environment in the usual place (/usr/bin/fluid) Here is what Timo did to force it to find Fluid:

FIND_PACKAGE(FLTK REQUIRED)
+
++SET(FLTK_FLUID_EXECUTABLE "/usr/bin/fluid")
+ IF(MINGW_PREFIX)
+       SET(FLTK_FLUID_EXECUTABLE "${MINGW_PREFIX}/bin/fluid")
+ ENDIF()

After this is fails at

CMakeFiles/Makefile2:4654: recipe for target 'plugins/LadspaEffect/swh/CMakeFiles/hermes_filter_1200.dir/all' failed

And other plugins fail as well. So... anyone have any suggestions for this?

[ghost]

Oh, also, wine dependency is gone (at least in my tests). lmms.io is the correct website in the description now...

fixing the formatting would be simple... just post what you want it to say and I can copy/paste it into the control file... it is very easy

[tresf]

@Israel- In response to your email to lmms-devel, shall we open a separate bug report for Ubuntu Wily? Perhaps this isn't the right place. I'd like to use the tracker because it makes it easy to tag people for help and crosslink to code locations and related bug reports.

-Tres

[tresf]

fixing the formatting would be simple... just post what you want it to say and I can copy/paste it into the control file... it is very easy

Great, however I think we can bundle the majority of the packaging logic directly into our codebase. If you have a script with "LMMS" or "https://lmms.io" hard-coded, we can churn that out with CMake, so let's try to focus our packaging to enable the computer do as much of the work for us. Ideally, make package (or perhaps a make dist or something) could do it all for you and you'd just have to get a MOTU-type person on the Ubuntu or Debian side to approve it. That's what we do for windows and we can start working our way toward the same for Ubuntu.

Also @falkTX is already doing the majority of this work for KXStudio, so there's no reason to reinvent the wheel if we don't need to, right? :+1:

[ghost]

@tresf I didn't reinvent the wheel, I used @falkTX packaging... though I did have to change soem things, as he has a very specialized build using some things that are special to his distro. It would be easy to

set(LMMS_WEBSITE "http://lmms.io")
set(CONTROLFILE "debian/control")
configure_file( ${CONTROLFILE}.in  ${CONTROLFILE})

we can do the same with the stuff in data like the desktop file and man page I am fine with bringing the packaging into the lmms codebase if you want. But, if we do that it will cause some hardship for @falkTX or myself.... as he uses staticlibs and something other than fltk IIRC... it has been a while since I looked at his packaging. He also has different depends in his control, and other things that would make this a bit tricky... I opened a new issue #2260

[tresf]

set(LMMS_WEBSITE "http://lmms.io")

I've started this via tresf/af3b638 which will be merged into master soon.

set(CONTROLFILE "debian/control")

The control file will be platform specific, so I'd like to put that in our new cmake/linux area.

we can do the same with the stuff in data like the desktop file and man page

Yes, we'll be moving this into cmake/linux moving forward.

if we do that it will cause some hardship for @falkTX or myself

Can you help explain how? If he's doing custom building now, he's already diverged so what would cause hardship? Furthermore, he plans to help us switch from FTLK to NTK eventually for the Zyn GUI, so based on previous conversations he's already on board with putting as much redundant logic upstream as possible. (correct me if I'm wrong here)

I opened a new issue #2260

Terrific. We should have CMake 3.3.x sorted with minimal effort. Thanks for the great info. :+1:

[ghost]

Oh... if FLTK is moving to NTK then I suppose his will be better suited. @falkTX would be the main person to consult about this... if the control file will need NTK, then I think most of his debian directory could be used just fine, if not all of it.

[falkTX]

FLTK will not move to NTK. NTK is a fork of FLTK, which btw only supports linux.

[ghost]

sorry... I meant, LMMS is moving to FLTK... It was a long day at work. I know very well FLTK is not going to change to NTK... I use FLTK to make small apps for simple tasks, it is much simpler than Qt or GTK, and is MUCH lighter as well :)

If it only works on Linux I suppose only our side would move to NTK, which would be fine to use your packaging. Don't you do static libraries, or something else custom to the upstream Debian? It has been a while since our last conversation.. @falkTX

[falkTX]

My own packaging is not usable for anything outside kxstudio, mostly because of the static libs I use. Moving to NTK is not that simple and FLTK works as-is, so I don't really see a need to change.

[tresf]

Thanks for the clarification @falkTX. So I suppose we will shelf the NTK talk for now, especially if the libraries won't easily work cross-platform.

@Israel- In regards to bundling for Ubuntu, it looks like we have a few items:

• [x] Fix our build scripts to work with cmake 3.3
• [ ] Add our missing resources to our /cmake/linux folder
• [ ] Add in some platform detection to fire the packaging process on Ubuntu, which should probably go here: /cmake/linux/CMakeLists.txt

I'll chime in later about cmake 3.3. I assume you can start a Pull Request with the rest so that we can discuss?

[tresf]

@Israel- Ubuntu 15.10 should compile now per cfbd53f.

Can you begin the other tasks?

[ghost]

@tresf great! I notified Timo who is in charge of merging my commit about the cmake issue. How do I specify Ubuntu/Debian only rules in CMakeLists.txt? I can work out doing the basics of creating a file to configure, but I do not know how to make it run only IF using a Debian based system.

[tresf]

I can help with some of that... Perhaps you should email then to me?

[tresf]

How do I specify Ubuntu/Debian only rules in CMakeLists.txt?

The most appropriate answer to this question is that we'll likely generate the DEB specific files for all Linux flavors, the non-Debian flavors simply won't use it, similar to something like this:

https://github.com/LMMS/lmms/blob/master/cmake/linux/lmms.spec.in

[ghost]

Hi I have been looking into this issue... I had one question... the current desktop file in Ubuntu contains this description

Linux Multimedia Studio - full VST support using Wine
 LMMS aims to be a free alternative to popular (but commercial and closed-
 source) programs like FruityLoops, Cubase and Logic giving you the ability of
 producing music with your computer by creating cool loops, synthesizing and
 mixing sounds, arranging samples, having more fun with your MIDI-keyboard
 and much more...
 .
 LMMS combines the features of a tracker-/sequencer-program (pattern-/channel-/
 sample-/song-/effect-management) and those of powerful synthesizers and
 samplers in a modern, user-friendly and easy to use graphical user-interface.

Obviously I will be changing Linux Multimedia Studio to @PROJECT_NAME_UCASE@ I will need to make a CMakeLists.txt in a debian directory and we (I?) will need to amend the base directory list to include my debian subdir

So... What in this description is work using? I want this to be maintainable for all Linux distros to use... we could make set(PROJECT_DESCRIPTION_EXTENDED "whatever you are cool with") in the main cmakelists. Any thoughts, comments ideas, etc?? Also... when I forked the repo the desktop file was not there... (in data) is this created somewhere? i am not extremely familiar with the github repo, as I have been using the bzr repo and merging it with github. If the desktop file doesn't exist I could add an ubuntu specific one in the debian folder. env QT_X11_NO_NATIVE_MENUBAR=1 probably wont mess anything up for other environments, right? I know JWM doesn't care about that sort of stuff, but anyone use GNOME?

[tresf]

the current desktop file in Ubuntu contains this description "Linux Multimedia Studio - full VST support using Wine"

We should certainly add it to a centralized location. If it needs to be very-very long, we can put it into a separate text file and read it using cmake file(READ filename variable ...), although I don't have a whole lot of experience publishing to an app store, so I'd trust your judgement for how long and how much formatting this file needs. We should be able to reuse it for other app stores, so the root of /cmake/ would be a good place or perhaps in the /doc/ folder.

Also... when I forked the repo the desktop file was not there... (in data)

When we cleaned up the root directory, we moved it, but it needs to be fixed anyway... It has all of the values hard-coded into it. Instead we should call it lmms.desktop.in and use CONFIGURE_FILE to spit it out with the proper text. Once we do that, we can decide where to put it (such as in the root of the build directory, etc)

env QT_X11_NO_NATIVE_MENUBAR=1 probably wont mess anything up for other environments, right? I know JWM doesn't care about that sort of stuff, but anyone use GNOME?

I vote we leave it for the desktop icon via https://github.com/LMMS/lmms/issues/488#issuecomment-38167989 unless someone complains as it just simplifies things.

[tresf]

I'm closing this in favor of #2932. Although a universal installer may be frowned upon by many Linux users, the efforts dedicated to a universal Linux installer will offer a much faster release cycle to end users without setting a particular preference to an OS. (e.g. why not RPM? type arguments). For now we'll leave the distro-specific packaging to each particular distribution. Please feel free to request this reopened if warranted.

[jasp00]

This problem would be fixed if we packaged for the Canterbury distro, a la LSB, but main distros are not fond of joining efforts.