search

LMMS / lmms

Cross-platform music production software
https://lmms.io
GNU General Public License v2.0
8.15k stars 1.01k forks source link

Package building on Linux #2556

Closed pbella closed 7 years ago

pbella commented 8 years ago

Something that would be very handy would be a means to locally build a Linux package (i.e. a .deb that can be built/installed locally, not THE Linux package) that would make it easier to install/test/remove a given build. This may just be a documentation issue as the existing build process has a package build product that appears to be the input to the package building process but I haven't seen any docs on how to get to a .deb...

tresf commented 8 years ago

If you want a .deb, this is a duplicate of #1620.

@Umcaruje not sure where the ux tag comes from.

@pbella Can you clarify this requirement please?

not THE Linux package

If you're ok with a .deb, our wiki has a skeleton of how @Israel- has done this in the past. We need help on this effort, so any work towards this goal is greatly appreciated.

pbella commented 8 years ago

I'm looking for something similar to, and that would help with #1620, but a bit different: a Debian, rather than Ubuntu package (similar, but not necessarily the same) To clarify what I mean (I'm spit-balling terms here as best I can given my current knowledge of the details of Linux .deb-based packaging):

1) THE Linux binary package would be the one that gets uploaded to the Debian package repository (i.e. it presumably has some minimal level of testing, is properly signed, etc.)

2) A Linux binary package (what I was originally looking for) is just the ability to take a local build and put it into a .deb that can be installed locally (i.e. build it in a VM, package it up so that I can install it on my host machine for testing) and I think is needed for 1. (with the addition of the signing steps that are in his cheat sheet)

3) A Linux source package is needed for 2 so that it can be rebuilt from source.

I took a look at #1620 but this appears to be a cheat sheet to get to 1 for the Ubuntu repos assuming that 3 already exists. (unless I'm missing something, the cheat sheet doesn't cover how to actually create 3) My original request was for how to take the binary build product from make to create #2 but let's change my request to how to take a snapshot of the source tree from git to create #3 since that will address my immediate need and sounds like it will help get to #1.

Once I figure out how to get 3, and then 2, done locally, I would be happy to volunteer to step up as the Debian package manager if that is a job that needs someone to fill. From reading some of the earlier conversation on this subject, I think what Isreal was saying is that with the Debian package in place, since Ubuntu is based on Debian, the Ubuntu package maintainers life is easier.

If we don't have anyone available right now who knows the details of how to get from 3 to 1, I'll be happy to start doing some research... (one thing I would need help with doing a 64-bit build with support for 32-bit VSTs... that's something I have not yet been able to get working properly)

tresf commented 8 years ago

Your response is giving me a headache.

If you're looking to make a self-contained installable package for Debian (similar to how Chrome distributes their software for Ubuntu), I think the aforementioned wiki link is in the right direction. We also have some community members that are packaging LMMS for platform such as Ubuntu and KXStudio which can really help with the build process, even if it's not exactly what you're aiming to do.

I've taken the initiative to do this for Apple. Toby did this for Windows. Linux shouldn't be all that bad and certainly less work if you can move away from shared libs as easily as Mac allows it. (I've linked the tutorials, but the relevant scripts are in various locations such as cmake, shell scripts, etc I'd be happy to link them specifically per request).

tresf commented 8 years ago

CPackDeb may also be a good resource for this.

pbella commented 8 years ago

Sorry... the combination of my lack of proper terminology and how packaging works (it is a bit of a different kind of animal given how Debian apps typically are packaged) didn't make for an easy read. I appreciate the pointers and I'll start poking around...

Umcaruje commented 8 years ago

@Umcaruje not sure where the ux tag comes from.

Well, easier installing of the program is User Expirience, isn't it?

Currently its a lot trickier to acquire the newest version of LMMS on Linux than it is for other platforms. Offering precompiled debs (and perhaps rpms) would allow people to get to the newest version much easier.

tresf commented 8 years ago

Well, easier installing of the program is User Expirience, isn't it?

Well, in that case, everything improves user experience. :smiling_imp: </offtopic>

Currently its a lot trickier to acquire the newest version of LMMS on Linux than it is for other platforms. Offering precompiled debs (and perhaps rpms) would allow people to get to the newest version much easier.

I wholeheartedly agree and I've always shared this feeling although I've had push back from the original devs about this topic. I can hunt down the old conversations if needed.

ghost commented 8 years ago

@pbella Sorry I have been so busy lately I just got in on this thread. There is a way to build a deb for the latest version of LMMS fairly easily in GNU/Linux as long as you are running a Debian based distro (Debian/Ubuntu/Mint/etc...) You can follow @tresf recommendation and read the documentation https://github.com/LMMS/lmms/wiki/Packaging-Ubuntu-PPA However this will only get you released versions like:
v1.1.3 This will not get you the latest snapshot, since LMMS devs do not put out snapshots, only releases. If you want to package the current one, you need to download the source of the master branch and manually merge with it.

This is all explained in the wiki page @tres referred you too. That said in Debian unstable you have v1.1.3 https://packages.debian.org/sid/lmms This is the same as Ubuntu Xenial http://packages.ubuntu.com/xenial/lmms So, to have bleeding edge LMMS you either need to run bleeding edge OS, or maintain a PPA for the latest version. If you want the unstable LMMS you need to manually merge with a source you download. i.e.

bzr branch ubuntu:xenial/lmms lmms
wget https://github.com/LMMS/lmms/archive/master.zip

(then convert the master.zip into a tar.gz file with a name similar to the version... something like lmms-1.1.3.tar.gz)

cd lmms
bzr merge-upstream  ../lmms-1.1.3.tar.gz
bzr commit

(type in your message) bzr builddeb -- -S -us -uc

pbuilder-dist YOURdistro build lmms_version-ubuntu revision number.dsc You need to use your distro version (i.e. lsb_release -a |grep -i codename)

pbuilder-dist xenial build../ lmms_1.1.3-0ubuntu1.ds
cd ~/pbuilder/xenial_result/
sudo apt-get autoremove lmms && sudo dpkg -i lmms*.deb

of course it is better to manually install the lmms && lmms-common version you specifically made if you have built more than one

pbella commented 8 years ago

@Israel- thanks, that fills in the blanks for me

skypce commented 8 years ago

Hello guys, i want contribute with a way to do it. with cpack: this is the recipe. Add this two lines to CMakeLists.txt of main folder of your project. SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "César R. Cid Méndez") SET(CPACK_PACKAGE_CONTACT "César R. Cid Méndez")

inside main project; mkdir build ; cd build ; cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr .. ; sudo cpack -G DEB ..

skypce commented 8 years ago

Hello again, i was uploaded the package to ppa : https://launchpad.net/~skypce/+archive/ubuntu/lmms The steps that i was use are the follow: sudo apt-get install dh-make bzr-builddeb bzr dh-make lmms 1.1.90 /home/skypce/Downloads/lmms-1.1.90.tar.gz cd lmms/debian rm ex EX

in lmms/debian/changelog

GNU nano 2.2.6 File: changelog

lmms (1.1.90-0ubuntu1) trusty; urgency=low

i was copy the original debian/control file from lmms-1.1.90.tar.gz to the new lmms folder.

bzr add debian/source/format bzr commit -m "Initial commit of Debian packaging."

debuild -S -kyourkey

dput ppa:skypce/lmms lmms_1.1.90-0ubuntu1_source.changes

/end/

dpkg-buildpackage I was added mi control version with the dependencies. and the 1.0 version. You can see in this version (1.0 control )2 packages: lmms , and lmms-common. i dont know why but when i compile the files with the 1.0 control generates files of 20kb may be you can fix it . Gretings.

I was added package depends to the control file. control-mine.zip control-1.0.zip

jasp00 commented 8 years ago

For Debian users, I could add the packaging to build experimental packages with pbuilder. I would upload these packages for the Debian stable version to my GitHub user pages. I have considered to create GitHub pages for LMMS and upload the packages of different distributions, but the management with Git would be painful.

trebmuh commented 8 years ago

@jasp00 : it could be very very handy to me in regards to https://github.com/LMMS/lmms/pull/2817

skypce commented 8 years ago

hello, i can compile lmms amd 64 for ubuntu 14.04 , this is the ppa : https://code.launchpad.net/~skypce/+archive/ubuntu/lmms-daily I was created a recipe if you want reuse it. best regards.

2016-06-14 17:17 GMT-04:00 Olivier Humbert notifications@github.com:

@jasp00 https://github.com/jasp00 : it could be very very handy to me in regards to #2817 https://github.com/LMMS/lmms/pull/2817

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/2556#issuecomment-226019031, or mute the thread https://github.com/notifications/unsubscribe/ACNMXSyKCwSCZQchseLoQq5M9hdYTbD9ks5qLxpNgaJpZM4HW3L_ .

musikBear commented 8 years ago

For Debian users, I could add the packaging to build experimental packages with pbuilder

I this also 'you' http://lmms.io/forum/viewtopic.php?f=4&t=5256

I must admit, that i am totally off my comfort zone in that topic. I cant even say if the topic is legit, or it is some kind of bogus click-for-russian-mail-order-brides :) But is it related to this topic?

tresf commented 8 years ago

@musikBear good link actually. Here's some more information surrounding the topic of unconventional Linux packaging: http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/

The important part is this:

"Snaps now work natively on Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity, and Xubuntu," Canonical's announcement says. "They are currently being validated on CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt and RHEL, and are easy to enable on other Linux distributions." (Ubuntu will continue to support deb packages, but developers can choose to package applications as snaps instead of or in addition to debs.)

But this is a relatively new technology and isn't the only one... here's another quote:

Snaps aren't the only new package managers for Linux distributions that aim to simplify installation of applications. There's also AppImage and OrbitalApps, Shuttleworth noted. Shuttleworth said he wouldn't criticize anyone for choosing a different application delivery system, but he argues that snaps offer better security.

So no worries, the forum post is spot-on and now you have some information to share back with the OP.

skypce commented 8 years ago

Hey Guys, i found this : https://github.com/probonopd/AppImageKit/blob/master/README.md http://appimage.org/

Packages compatible with all linux distro and with none dependency. enjoy

2016-06-15 8:36 GMT-04:00 Tres Finocchiaro notifications@github.com:

@musikBear https://github.com/musikBear good link actually. Here's some more information surrounding the topic of unconventional Linux packaging: http://arstechnica.com/information-technology/2016/06/goodbye-apt-and-yum-ubuntus-snap-apps-are-coming-to-distros-everywhere/

The important part is this:

"Snaps now work natively on Arch, Debian, Fedora, Kubuntu, Lubuntu, Ubuntu GNOME, Ubuntu Kylin, Ubuntu MATE, Ubuntu Unity, and Xubuntu," Canonical's announcement says. "They are currently being validated on CentOS, Elementary, Gentoo, Mint, OpenSUSE, OpenWrt and RHEL, and are easy to enable on other Linux distributions." (Ubuntu will continue to support deb packages, but developers can choose to package applications as snaps instead of or in addition to debs.)

But this is a relatively new technology and isn't the only one... here's another quote:

Snaps aren't the only new package managers for Linux distributions that aim to simplify installation of applications. There's also AppImage and OrbitalApps, Shuttleworth noted. Shuttleworth said he wouldn't criticize anyone for choosing a different application delivery system, but he argues that snaps offer better security.

So no worries, the forum post is spot-on and now you have some information to share back with the OP.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/2556#issuecomment-226173995, or mute the thread https://github.com/notifications/unsubscribe/ACNMXbjfQQFrovm9EvGUPNp9fSx1bHO6ks5qL_HEgaJpZM4HW3L_ .

jasp00 commented 8 years ago

I was considering to add the packaging that would work for Debian Jessie and Ubuntu Trusty, but if Snap or AppImage are preferred, I will not add it. Of course, both Debian packaging and Snap package could be added.

skypce commented 8 years ago

Hello, i was trying to generate a appImage . i was attached the result file.

2016-06-17 16:12 GMT-04:00 Javier Serrano Polo notifications@github.com:

I was considering to add the packaging that would work for Debian Jessie and Ubuntu Trusty, but if Snap or AppImage are preferred, I will not add it. Of course, both Debian packaging and Snap package could be added.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/2556#issuecomment-226870020, or mute the thread https://github.com/notifications/unsubscribe/ACNMXb_wQ3diIKorKN1EX8UjMUmYe5teks5qMv-VgaJpZM4HW3L_ .

skypce commented 8 years ago

hey guys, i can create a AppImage of latest master branch of git. only works in 64 bits. https://drive.google.com/file/d/0B8BXTOusl5b6Zjl3WVpxY1JFbkU/view?usp=sharing

2016-06-30 11:46 GMT-04:00 skypce skypce@gmail.com:

Hello, i was trying to generate a appImage . i was attached the result file.

2016-06-17 16:12 GMT-04:00 Javier Serrano Polo notifications@github.com:

I was considering to add the packaging that would work for Debian Jessie and Ubuntu Trusty, but if Snap or AppImage are preferred, I will not add it. Of course, both Debian packaging and Snap package could be added.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/LMMS/lmms/issues/2556#issuecomment-226870020, or mute the thread https://github.com/notifications/unsubscribe/ACNMXb_wQ3diIKorKN1EX8UjMUmYe5teks5qMv-VgaJpZM4HW3L_ .

jasp00 commented 8 years ago

Rather than the AppImage, we need the steps to build the image and integrate them into the Travis build.

skypce commented 8 years ago

Sure Guys, i will share with you step by step: Step 1: Generate a DEB Package , i was used the follow way to do it: SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "César R. Cid Méndez") SET(CPACK_PACKAGE_CONTACT "César R. Cid Méndez") inside main project; mkdir build ; cd build ; cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr .. ; sudo cpack -G DEB ..

Step 2 : When you have the deb package: i use the google-chrome recipe: (https://github.com/probonopd/AppImageKit/wiki/Bundling-Google-Chrome) you can see in right aside a lot of more recipes. You need create a lmms.AppImage folder Inside lmms.AppImage put the generated deb file. Inside lmms.AppImage execute the follow command: "find ../ -name .deb -exec dpkg -x {} . \;" find . -name .desktop -exec cp {} . \; find -name product_logo_48.png -exec cp {} google-chrome.png \; sed -i -e 's|/usr/bin/lmms %U|AppRun|g' lmms.desktop cat > ./AppRun <<\EOF

!/bin/sh

HERE=$(dirname $(readlink -f "${0}")) export LD_LIBRARY_PATH="${HERE}"/usr/lib:$PATH "${HERE}"/usr/bin/lmms $@ EOF chmod a+x ./AppRun

Try to run ./AppRun

remove deb file from lmms.AppImage wget -c "https://downloads.sourceforge.net/project/portable/64bit/AppImageAssistant%200.9.3-64bit chmod a+x "AppImageAssistant 0.9.3-64bit" mv AppImageAssistant 0.9.3-64bit appimageassistant-64 appimageassistant-64 ./lmms.AppImage/ ./lmms.AppImage That is all , by moment, i will study how generate a travis Build

skypce commented 8 years ago

Sure Guys, i will share with you step by step: Step 1: Generate a DEB Package , i was used the follow way to do it: SET(CPACK_DEBIAN_PACKAGE_MAINTAINER "César R. Cid Méndez") SET(CPACK_PACKAGE_CONTACT "César R. Cid Méndez") inside main project; mkdir build ; cd build ; cmake -DCMAKE_INSTALL_PREFIX:PATH=/usr .. ; sudo cpack -G DEB ..

Step 2 : When you have the deb package: i use the google-chrome recipe: (https://github.com/probonopd/AppImageKit/wiki/Bundling-Google-Chrome) you can see in right aside a lot of more recipes. You need create a lmms.AppImage folder Inside lmms.AppImage put the generated deb file. Inside lmms.AppImage execute the follow command: "find ../ -name .deb -exec dpkg -x {} . \;" find . -name .desktop -exec cp {} . \; find -name product_logo_48.png -exec cp {} google-chrome.png \; sed -i -e 's|/usr/bin/lmms %U|AppRun|g' lmms.desktop cat > ./AppRun <<\EOF

!/bin/sh

HERE=$(dirname $(readlink -f "${0}")) export LD_LIBRARY_PATH="${HERE}"/usr/lib:$PATH "${HERE}"/usr/bin/lmms $@ EOF chmod a+x ./AppRun

Try to run ./AppRun

remove deb file from lmms.AppImage wget -c "https://downloads.sourceforge.net/project/portable/64bit/AppImageAssistant%200.9.3-64bit chmod a+x "AppImageAssistant 0.9.3-64bit" mv AppImageAssistant 0.9.3-64bit appimageassistant-64 appimageassistant-64 ./lmms.AppImage/ ./lmms.AppImage That is all , by moment, i will study how generate a travis Build

jasp00 commented 8 years ago

There are problems with an AppImage:

I am not sure a package without dependencies is the way to go. Should a big package for Linux be provided?

tresf commented 8 years ago

Should a big package for Linux be provided?

In short, yes but this is a cultural adoption by Linux, not necessarily a LMMS decision. If AppImage is lucky enough to actually succeed (I remember all the hype LinSpire had around Click-N-Run) then we may finally be in a positions where applications for Linux "just work".

On the contrary, if Linux continues to be of the mindset that everything must be shared libraries, then this idea will continue to fail.

Including Wine increases the size a lot.

We'd never do that. Ideally, if Wine's available, we use it. If not, we don't. Bundling Wine is arguably the same thing as just making LMMS a Wine bottle to begin with and shipping the entire Windows version as an AppImage. As ridiculous as this sounds, that's what the author of the Packt book used to run LMMS on his Mac per something like this.

Plug-ins in included dependencies may not work. Dependencies may have to be patched and recompiled.

Right, we'd have to do the same type of packaging we do today for Mac and Windows where we distribute the exact version used during the build process. Qt for Mac has a tool called macdeployqt which does 90% of this for us. Perhaps there's a utility for Linux which assists with this.

There is no optional dependency information. It is less clear for a user that installing certain packages will enhance LMMS (PAT and SF2 files, samples, LADSPA plug-ins). Including optional dependencies, if they work, increases the size of the AppImage.

The biggest complaint I can see from users (which is still a problem today) is the redundant LADSPA plugins. We don't really bundle any well known instrument-patches (PAT, SF2, GIG), so that would be a non-issue. I'm not sure the relevance of the samples collection, we'd always want to bundle that AFAIK.

Included dependencies override installed dependencies. There may be configuration incompatibilities with the installed environment.

For LMMS, sure. I'd hope it would work this way but I agree we'd have to make sure they're not introduced as shared libraries to the system. That would cause a lot of problems.

I too am not sure if this is a good idea, but I'm willing to try it. Currently, LMMS is about 25-30MB on Mac and Windows. Both Mac and Windows ship without the majority of what's needed for LMMS to run, so the majority of dependencies are all bundled and packaged into our installers. It seems wasteful, but it's not a new idea and it's one I would like to see tried on Linux. :+1:

jasp00 commented 8 years ago

LMMS is not relocatable yet. An environment with XZ compression (I forgot libgig) takes up 42 MiB. A Linux installer to $HOME/.lmms.app would be more convenient to cut startup time. That could also make desktop menu and MIME type work.

What bothers me about AppImage is that it requires FUSE. I would rather create a self-extracting file without that requirement.

tresf commented 8 years ago

What if we used makeself and rolled our own? In regards to the home install, I'm neutral. Non-root installs have their pluses and minuses, but I tend to drift toward the system-wide installers, personally.

tresf commented 8 years ago

@jasp00 how do other projects get their packages to the masses? I don't think anyone's opposed to simply using the conservative channels, we just lack the help to keep on top of it for Ubuntu better yet Debian, Fedora, Arch, etc.

jasp00 commented 8 years ago

What if we used makeself and rolled our own?

Let us try that, install to $HOME/.lmms-version, and see the download count. Someone could make a Qt installer with more features later.

how do other projects get their packages to the masses?

Some examples:

Distributions are keeping LMMS up to the latest stable version. A universal executable should be enough for release candidates and nightly builds.

probonopd commented 8 years ago

Also see https://lmms.io/forum/viewtopic.php?t=5581. The AppImage "without Qt 4" works for me. The one with Qt is not packaged correctly (only half of Qt is bundled properly) and hence will not run.

probonopd commented 8 years ago

Qt for Mac has a tool called macdeployqt which does 90% of this for us. Perhaps there's a utility for Linux which assists with this.

There is: linuxdeployqt. It can even bake an AppImage for you.

jasp00 commented 8 years ago

It can even bake an AppImage for you.

https://github.com/LMMS/lmms/issues/2556#issuecomment-233216697

probonopd commented 8 years ago

LMMS is not relocatable yet

The "yet" sounds like it is being worked on. In the meantime, we can binary-patch the LMMS executable as a workaround.

An environment with XZ compression (I forgot libgig) takes up 42 MiB.

That's not much at all. There are much larger AppImages.

A Linux installer to $HOME/.lmms.app would be more convenient to cut startup time.

Have you tried AppImage startup time and do you find it too slow?

That could also make desktop menu and MIME type work.

Using the desktopintegration script inside the AppImage, MIME types work with AppImages.

What bothers me about AppImage is that it requires FUSE.

Why does it bother you? FUSE is installed on almost every desktop distribution by default these days. Also, you can always just loop-mount the AppImage using kernel mounting if you like.

I would rather create a self-extracting file without that requirement.

The next AppImage iteration could make it possible to self-extract if FUSE is not present, if that is really a concern.

jasp00 commented 8 years ago

Sorry about your long answer. The only point was that AppImage requires FUSE. Mounting is a privileged action and LMMS does not require such a privilege. If mounting is not an option, then a self-extractable is the way to go. The AppImage should work like a self-extractable.

The file should be small, so we use XZ compression. An issue is that we have tried makeself and, besides minor nuisance, it works. It would be interesting to switch to AppImage if the file could be mounted when possible while still being small. But as you have noticed in your experiment with squashfs, XZ compression makes a slow application start. This is why LMMS is installed instead of being run directly; we end up using an installer like on Windows and Mac.

I do not see the point in using AppImage in our scenario. What would be the advantage?

jasp00 commented 8 years ago

What would be the advantage?

Embedding digital signatures sounds like an advantage; we could use AppImage as an improved installer. We should consider AppImage in the future.

probonopd commented 8 years ago

If mounting is not an option, then a self-extractable is the way to go.

You can

  1. FUSE mount (default)
  2. kenel-loopmount (needs root; not default; faster)
  3. extract the AppImage using --appimage-extract (self-extractable; implemented today in https://github.com/probonopd/appimagetool)
  4. extract the AppImage using tools like unsquashfs

What would be the advantage?

Another one: Portable use cases. Put LMMS on a (Live) USB stick. Be able to run from that.

probonopd commented 8 years ago

Wrote an AppImage recipe that converts the deb from the PPA into an AppImage: https://github.com/probonopd/AppImages/blob/master/recipes/meta/LMMS.yml

Try there AppImage here: https://bintray.com/probono/AppImages/LMMS/_latestVersion#files

Some fine-tuning is expected to be needed. Let me know how it goes. Would this project be interested in providing an official one?

jasp00 commented 7 years ago

Would this project be interested in providing an official one?

I cannot give an answer yet. We need to tweak some libraries for LMMS first (Qt5). We should consider AppImage afterward.

jasp00 commented 7 years ago

Would this project be interested in providing an official one?

I cannot give an answer yet. We need to tweak some libraries for LMMS first (Qt5). We should consider AppImage afterward.

Serkan-devel commented 7 years ago

Any updates in appimage support?

tresf commented 7 years ago

Any updates in appimage support?

None, but if you have experience with relinking and packaging Linux applications, please offer some assistance over at #2932, we could use the help!

Serkan-devel commented 7 years ago

I already have problems packaging by myself (https://github.com/probonopd/AppImages/issues/237) but I can try

tresf commented 7 years ago

That bug you linked... That script right before the copy is probably bombing out, could be a multitude of reasons but probably a basic script error that's not getting echoed to the screen properly and erroring in the wrong place and never being caught. We're moving to set -e for this reason.

Our packaging problems are more library copying and relinking related. AppImage will be possible once the . runs are working. As far as I understand they're both a snapshot of the app and all dependencies. The process of copying should actually be quite trivial.

But we only have a few volunteers and very few with packaging experience, hence the request for help. :)

tresf commented 7 years ago

Actually you aren't specifying the right extract folder when you extract the tarball, that logic won't work. Also expect everything to use a random directory inside tmp. What is so attractive about AppImage btw? Makeself does the same exact thing and is very universal.

probonopd commented 7 years ago

Any updates in appimage support?

Please see https://github.com/LMMS/lmms/issues/2556#issuecomment-259509205 - I have made AppImage no one has commented on so far.

If people like, we can also package the build artifacts from Travis CI as AppImages. Let me know if there is interest.

probonopd commented 7 years ago

What is so attractive about AppImage btw?

Providing an AppImage would have, among others, these advantages:

Here is an overview of projects that are already distributing upstream-provided, official AppImages.

Makeself does the same exact thing and is very universal.

Makeself requires you to unpack an archive, adding one more step do do, that can also take some time. Also there is no automatic desktop integration (like with the optional appimaged daemon). Finally, it is not as trivial to move an app to another machine once it has been unpacked.

But the other way around, AppImages can entirely replace the need for makeself:

./some.AppImage --appimage-extract unpacks the contents of the AppImage, hence doing everything makeself can do, as a side product.

tukkek commented 7 years ago

Every single application I've seen that uses AppImage just works ™. I think that is saying a lot since, even today, downloading and running Linux apps is always a shot in the dark unless you're installing them directly from your distribution's repositories.

Just wanted to add that I'm very happy with how it worked for me as an user in the past for other projects. If Debian continues to offer a lmms package I'll always install it from the repositories but an AppImage is a great alternative if the Debian version ever goes out-of-date or if I install another distribution in the future.

tresf commented 7 years ago

I mean over the tried and trued .run. Portable, self contained applications are nothing new. It's how Mac and Windows do it.

The diff feature seems OK if a package manager is being used, and signing is good if you know who to trust, but the other points are just describing how a self contained app works, not why it's better than a .run.

All serious apps I've installed are .run files and they work just fine and install on everything. They are a lower common denominator and .run is what we'll start with. Once that works we can wrap the same process into another container format.

eagles051387 commented 7 years ago

Tukkek you do know if someone is willing to package and put them in a ppa repository you can get the latest versions of lmms for your version of debian/ubuntu from there.

Regards,

Jonathan Aquilina

On 2017-05-14 21:44, tukkek wrote:

Every single application I've seen that uses AppImage just works(tm). I think that is saying a lot since, even today, downloading and running Linux apps is always a shot in the dark unless you're installing it directly from your distribution's repositories.

Just wanted to add that I'm very happy with how it worked for me as an user in the past for other projects. If Debian continues to offer a `lmms package I'll always install it from the repositories but an AppImage is a great alternative if the Debian version ever goes out-of-date or if I install another distribution in the future.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2].

Links:

[1] https://github.com/LMMS/lmms/issues/2556#issuecomment-301335086

tukkek commented 7 years ago

Comparing AppImages with run files makes it clear you have no idea what you're talking about and didn't even bother reading the thread and the thoughtful, thorough comments other people wrote here.

@eagles051387 the current Debian package (on the testing/stretch release) is the latest stable version of LMMS. It's currently being maintained by 4 people plus the whole Debian Edu team so chances are that it will be kept up-to-date and healthy whenever 1.2 and future releases eventually come out :)