Repository navigation
Ubuntu packaging #1620
Description
Better Ubuntu Packaging:
- Our information for
stable-1.0could 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
Activity
badosu commentedon Jan 13, 2015
@CRANK123 For VST support.
badosu commentedon Jan 13, 2015
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 commentedon Jan 14, 2015
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 commentedon Jan 14, 2015
@tresf And even those that exist for linux we don't support, if I am not mistaken.
tresf commentedon Jan 14, 2015
Correct.
diizy commentedon Jan 14, 2015
On 01/14/2015 06:23 AM, Amadeus Folego wrote:
We do, via Carla.
Support is still experimental though, so things like automations aren't
supported yet.
diizy commentedon Jan 14, 2015
On 01/14/2015 03:35 AM, Tres Finocchiaro wrote:
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 commentedon Jan 15, 2015
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? ð
4 remaining items
tresf commentedon Aug 13, 2015
I've started this via tresf/af3b638 which will be merged into master soon.
The control file will be platform specific, so I'd like to put that in our new
cmake/linuxarea.Yes, we'll be moving this into
cmake/linuxmoving forward.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)
Terrific. We should have
CMake 3.3.xsorted with minimal effort. Thanks for the great info. ðfalkTX commentedon Aug 14, 2015
FLTK will not move to NTK.
NTK is a fork of FLTK, which btw only supports linux.
falkTX commentedon Aug 14, 2015
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 commentedon Aug 14, 2015
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:
/cmake/linuxfolder/cmake/linux/CMakeLists.txtI'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 commentedon Aug 22, 2015
@Israel- Ubuntu 15.10 should compile now per cfbd53f.
Can you begin the other tasks?
tresf commentedon Aug 22, 2015
I can help with some of that... Perhaps you should email then to me?
tresf commentedon Aug 22, 2015
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
tresf commentedon Aug 29, 2015
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.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.inand useCONFIGURE_FILEto spit it out with the proper text. Once we do that, we can decide where to put it (such as in the root of thebuilddirectory, etc)I vote we leave it for the desktop icon via #488 (comment) unless someone complains as it just simplifies things.
tresf commentedon Apr 6, 2017
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 commentedon Apr 8, 2017
This problem would be fixed if we packaged for the Canterbury distro, a la LSB, but main distros are not fond of joining efforts.