Package building on Linux

[pbella]

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]

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]

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]

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]

CPackDeb may also be a good resource for this.

[pbella]

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]

@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]

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

Well, in that case, everything improves user experience. 😈 </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]

@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]

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

[skypce]

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]

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

• Initial release (Closes: #nnnn)

  -- Cesar R. Cid Mendez skypce@gmail.com Tue, 15 Mar 2016 22:33:45 -0300

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]

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]

@jasp00 : it could be very very handy to me in regards to #2817

[skypce]

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 #2817

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#2556 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACNMXSyKCwSCZQchseLoQq5M9hdYTbD9ks5qLxpNgaJpZM4HW3L_
.

[musikBear]

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]

@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]

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
#2556 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACNMXbjfQQFrovm9EvGUPNp9fSx1bHO6ks5qL_HEgaJpZM4HW3L_
.

[jasp00]

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]

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
#2556 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACNMXb_wQ3diIKorKN1EX8UjMUmYe5teks5qMv-VgaJpZM4HW3L_
.

[skypce]

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
#2556 (comment), or mute
the thread
https://github.com/notifications/unsubscribe/ACNMXb_wQ3diIKorKN1EX8UjMUmYe5teks5qMv-VgaJpZM4HW3L_
.

[jasp00]

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

[skypce]

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]

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]

There are problems with an AppImage:

• 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.
• Including Wine increases the size a lot.
• Plug-ins in included dependencies may not work. Dependencies may have to be patched and recompiled.
• Included dependencies override installed dependencies. There may be configuration incompatibilities with the installed environment.

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

[tresf]

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. 👍

[jasp00]

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]

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]

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]

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]

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]

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]

Any updates in appimage support?

[tresf]

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]

I already have problems packaging by myself (AppImageCommunity/pkg2appimage#237) but I can try

[tresf]

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]

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]

Any updates in appimage support?

Please see #2556 (comment) - 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]

What is so attractive about AppImage btw?

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

• Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)
• One app = one file = super simple for users: just download one AppImage file, make it executable, and run
• No unpacking or installation necessary
• No root needed
• No system libraries changed
• Works out of the box, no installation of runtimes needed
• Optional desktop integration with appimaged
• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate
• Can optionally GPG2-sign your AppImages (inside the file)
• Works on Live ISOs
• Can use the same AppImages when dual-booting multiple distributions

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]

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]

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]

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] #2556 (comment)

[tukkek]

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 :)

[Umcaruje]

so @probonopd I just tried your Appimage, and I must say I'm impressed with this. The size is similar to the one of our windows installers, it also has an option to integrate with your environment and it works like a charm. Also everything works with a click and it's not intrusive to the system. I love it, and I would really be interested if we could provide this to the users, and if we could get an automated Travis task to do this.

[tresf]

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

so @probonopd I just tried your Appimage, and I must say I'm impressed with this.

If it doesn't contain the majority of dependent libraries then it won't work cross-distros.

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

• Works for most Linux distributions (including Ubuntu, Fedora, openSUSE, CentOS, elementaryOS, Linux Mint, and others)

makeself already does this.

• One app = one file = super simple for users: just download one AppImage file, make it executable, and run

makeself already does this.

• No unpacking or installation necessary

makeself already does this.

• No root needed

makeself has this ablity, and already discussed here.

• No system libraries changed

makeself can do this.

• Works out of the box, no installation of runtimes needed

makeself can do this.

• Optional desktop integration with appimaged

makeself can do this, albeit manually

• Optional binary delta updates, e.g., for continuous builds (only download the binary diff) using AppImageUpdate

makeself cannot do this.

• Can optionally GPG2-sign your AppImages (inside the file)

I've never signed a .run before, so this is something I don't know about.

• Works on Live ISOs

makeself can do this.

• Can use the same AppImages when dual-booting multiple distributions

rare edge-case but makeself can do this too.

[you] didn't even bother reading the thread and the thoughtful, thorough comments other people wrote here.

Please don't ad hominem. Makeself uses tools available on more distros for a longer period of time so it truly is a lower common denominator regardless of which is preferred. We welcome the start of this, but the work is inevitably redundant with the .run task. The hard part is getting the dependencies sorted, which requires a bunch of recursive copying and re-linking. If linuxdeployqt (comment) makes this simpler, let's get a prototype PR going.

We also need to know which OSs ship with AppImage support out of the box and which don't. We need to know our deployment scope.

makes it clear you have no idea what you're talking about

Having installed a .run on old, new and obscure OSs and used .run files as an end-user by major companies like nVidia , VMWare, JetBrains we should focus on the technical differences. We really don't tolerate mudslinging here, so if we can keep the conversation civil and focus on the technology that will yield the fastest progression. If something I've said seems counterproductive to this argument, please focus on that so that we can strive for better communication.

At the end of the day, I don't believe these tasks are separate. Both system move shared objects and binaries into a directory so an application can be run. What container we wrap the files in is a mostly superficial decision because 1. To validate a "good" signature versus "bad" requires a chain of trust. This is the same on all OSs, really. 2. The diff or delta feature is only useful for auto-updates which I'm not sure we'll be providing out of the gate. So I stand by my original statements. I hope you take them purely as technological observations.

[tukkek]

If your best argument is "makeself does everything that AppImage does" then why are you so invested against AppImage? You just proved they're both on par - except me and others here seem to think AppImage is a better solution. If you have tried to express any reason why makeself is clearly superior then it didn't come across for me and I, politely and nonadhominenly ask that you please try once more.

obscure OSs

The fact that run files are supported on legacy systems is moot. LMMS doesn't need or should care about old systems. Linux isn't like Windows or Mac, you can always upgrade your system, with plenty of up-to-date options for legacy hardware. Also, LMMS isn't a commercial project, even if one or two people simply cannot update their systems no matter what, doesn't mean this should become a development priority - quite on the contrary: it's a time, effort and energy sink while 99,9% of the users are running modern Linux distros and will be able to use both run and AppImage regardless.

nVidia , VMWare, JetBrains

So what? The use case is vastly different. They're installing software, which I agree .run files are perfect for and AppImages aren't. That's not what the AppImage discussion is about. LMMS already has packages in several repositories and a PPA for system installation. Meanwhile, AppImage is becoming a fast standard for self-contained Linux package distribution, which seems to be what it's being discussed for.

Trying to advance the discussion, though: honestly, does anyone here see a problem offering both an AppImage and a run file? There seem to be several people here in favor of offering an AppImage and one in favor of a run file. The OSS ethos values action, not talk. Let each party build their own build scripts and offer both packages for download on the website. This thread seems to indicate an AppImage is already being produced, let whoever wants to create a .run create a build as well.

I'm not saying that LMMS should indeterminately and officially maintain two build scripts - just that as long as someone is willing to contribute them in a 100% ready state, there is no downside to offering both files for download. With time, it will become clear which one has the most technical merits or shortcomings and in the future it will be easy enough to drop one of them and maintain the other one if that's necessary.

[tukkek]

Also everything works with a click and it's not intrusive to the system

I don't think that makeself can beat this. As far as I understand it extracts files into a temporary folder instead of mounting an image like AppImage does. This means that it's pretty easy to run into free-space issues, especially if the run file uses /tmp/ by default, which many distributions use a separate (and thus fixed-size) partition for - not to mention "live" distributions which would have to unpack those directly into memory instead of reading directly from whatever storage the AppImage is located at.

[tresf]

This is the wrong place to cast a vote for a package bundler. If there's limitations, point them out. Anything else is simply wasting valuable developers time. Please stop arguing and keep the content technical or this thread will be locked in favor of a PR.

Now to answer the actual content of these long-winded replies...

There seem to be several people here in favor of offering an AppImage and one in favor of a run file.

This isn't a democracy. We accept code that works and the admins that run the project try their best to weight the differences when a conflict arises. Opening a PR is a good way to prove a point. Then we can test the code instead of speculate about it.

Also everything works with a click and it's not intrusive to the system

I don't think that makeself can beat this

We'd all love that, but I remember something being said about setting the file executable. If that's true, it's not a single-click. If we can set executable flag prior to download (or buy a trusted certificate to unlock this) let's talk about that. It's relevant.

Although I do agree that double-clicking a file is easier than executing it through terminal, it's still not correcting the packing problems which will occur regardless. It took quite a while to fix the linking and bundling problems with Mac, so if we can focus on the viability of the package instead of the container format, we'll be closer to offering this as a download.

this means that it's pretty easy to run into free-space issues, especially if the run file uses /tmp/ by default

If /tmp fills with a < 100MB installer, the user has much bigger problems. It's a nice safeguard, but shouldn't be considered a show-stopper. There is an equal and opposite edge-case where the main volume lacks the space as well. Let's not bikeshed over /tmp.

"live" distributions which would have to unpack those directly into memory

This is true for all storage on a live partition. Not sure how this is different. Has someone tried our .run installer on a live CD and proven that it runs into such /tmp problems? I've installed .run files on ChromeOS which has a read-only /tmp and managed to get it to all work silently, seamlessly. The technology does work.

AppImage is becoming a fast standard for self-contained Linux package distribution, which seems to be what it's being discussed for.

I think this is a good selling point but we should also identify projects which have adopted it, especially if they're Qt based so that we can learn from their packaging system.

I'm not saying that LMMS should indeterminately and officially maintain two build scripts

Well, they aren't necessarily two separate scripts. If an AppImage tool can bundle better (e.g. linuxdeployqt), we can wrap the outputted directory in whatever container we choose (tarball, .run, or AppImage). They aren't mutually exclusive.

We're just waiting on someone getting a successful bundle. Wrapping the .deb into an AppImage isn't necessarily the solution to that, we'd want to make a pure AppImage and chain it into a CMake packaging target.

[tukkek]

I remember something being said about setting the file executable

I installed an nvidia driver yesterday (they use .run files) and had to set the execution permission manually. makeself clearly doesn't have an answer to this. Unless you're packaging the file on a .tar.gz or similar format that supports +x then there is no way around this as far as I know - and of course, you shouldn't be distributing an AppImage or .run file inside a compressed archive regardless - and if you were to do it, doesn't matter which format the file inside is.

There is no easy way around this because it's a Linux security feature, making this point near-irrelevant. If it was very easy for people to just automatically set +x to any Linux download it would simply make the entire point of having a permission useless. If that is a big problem for people here, put the AppImage or .run file inside a .tar.gz, even though it'd seem very silly to me.

If /tmp fills with a < 100MB installer, the user has much bigger problems

Today. Who knows what the installer size will be 2 years from now? Nobody can predict the future. This becomes an even bigger issue on live distributions because no matter where the data is extracted at (/tmp, /home, etc), it wil reside in memory, which is almost always the rarest resource on any live session.

This is true for all storage on a live partition. Not sure how this is different.

If you're not sure then you missed my point entirely: people using Live distributions, very often, will pack their "mobile" apps on a removable device or into the live media itself (if they've built it themselves), avoiding having to redownload whatever applications are needed after every boot. This means that with an AppImage the files reside only on a USB drive or the live media itself (say, a DVD) while with a run file it would have to also be extracted into memory before use.

If you're thinking about the use case of a live CD user downloading the entire package from the website after every boot, then, in the case of a run image, the user needs to have it downloaded (100MB), extracted (another 100MB or more) and then running (another 100MB or so, I think). Your "small" 100MB package just became a 300MB+ memory hog in this case - which is definitely a respectable number for a modest computer trying to run a full desktop environemnt, plus any other apps needed.

Anyway, I'm not sure if Live sessions should be a concern at all for LMMS, I just brought it up initially because someone mentioned them here prior. It's easy to see though that AppImage makes this a complete non-issue, making it more suitable, at least in this case, for self-contained execution.

Wrapping the .deb into an AppImage isn't necessarily the solution to that, we'd want to make a pure AppImage and chain it into a CMake packaging target.

Explain to me why, when @probonopd already has a working AppImage, verified by yourself, using a very simple YAML recipe? You were advocating for keeping this discussion strictly towards the benefits of each packaging method. What technical advantages does building an AppImage from scractch have over a deb-based one?

[tresf]

What technical advantages does building an AppImage from scractch have over a deb-based one?

Two reasons...

1. We don't yet have a deb packaging script.
2. Because a deb package is a distro-specific package format. In short, debian packages generally don't bundle what they need, they fetch them. Thus, wrapping an LMMS deb file into yet another package format is a bad permanent design.

I installed an nvidia driver yesterday (they use .run files) and had to set the execution permission manually. makeself clearly doesn't have an answer to this.

No one made claim that it did. It was only a rebuttal to the glittering generality of this statement.

" just download one AppImage file, make it executable, and run

If you're not sure then you missed my point
@probonopd already has a working AppImage, verified by yourself

Lets, please avoid ad hominem, it never ends well. And I didn't verify anything was working, BTW.

Who knows what the installer size will be 2 years from now?

Let's use arguments we can safely measure, but to entertain the question, the project maintainers have a pretty good idea. It forces us a bit off-topic to explain, but we at least have the best idea as we've seen the project grow for several years, so we are in the best place to make an educated guess. 0.4.5 was released in 2009 at 17MB. 1.2.0 will be released in 2017 at about 30MB. Size varies about 5-10MB between platforms, so in 2 years the file size will be a comparable gain. About 5MB of that gain can be directly attributed to switching from Qt4 to Qt5, btw.

Your "small" 100MB package just became a 300MB+ memory hog

Taking 100MB hypothetical out of context and arguing with it is misleading. 40MB * 3 = 120MB which is much more realistic and practical. Second, unless using the --keep option, makeself cleans this data up after itself, so it's really 40MB * 2 = 80MB. Third, users should cleanup downloads, that's their problem not ours. So from a disk utilization perspective, the net amount is going to be about the same with delta minus the storage difference between compressed versus uncompressed. I would expect the compressed archive to be a smaller size but only at the cost of CPU cycles. I don't know enough about how FUSE AppImage performance compares against a plain-old-file so this is best measured once we have an image created.

Live distributions, very often, will pack their "mobile" apps on a removable device or into the live media itself (if they've built it themselves), avoiding having to redownload whatever applications are needed after every boot. This means that with an AppImage the files reside only on a USB drive or the live media itself (say, a DVD) while with a run file it would have to also be extracted into memory before use.

Thanks for the background information. This is an interesting use-case. I am more familiar with users baking software directly onto the medium. I can see how the FUSE support makes this less burdensome, like plugging in a removable drive and running.

I'm not sure if Live sessions should be a concern at all for LMMS,

I'm not either, but the live CD argument does raise some good points and the marketing appeal of making the latest LMMS available on a live medium has its merits.

So what I'm reading is that AppImage is extremely similar to the way Apple does the DMGs, except:

1. AppImage saves some steps by skipping the intermediary mount, extract, unmount steps (whether this has performance implication is TBD)
2. Contrary to Apple, AppImage doesn't provide a way to click-and-run the executable without changing execute permission. At least not yet. If the distros agree on a way to digitally sign these to avoid the chmod +x step, this would put it on par with how Windows and Mac do it today and would be a major advantage AppImage would have over .run.

On a side note, having such a "Portable" installation does carry it's own caveats, mostly caused by working paths and relative paths, but we've done a pretty good job of coding for these caveats.

From a support perspective, writing the installer ourselves yields predictable install locations, which is a plus from the project's perspective. The vast user-base creates a lot of support chatter. Controlling the manner in which an application is installed and registered with the OS can offer some advantages.

Mac gets around this problem by just having a culture that expects everything dragged to /Applications. I'm not aware of such a place that exist for the Linux desktop, so we'd loose the predictability of deployments, which can also effect the upgrade path, if we ever employ one.

But this is all just chatter until it happens. If someone can prepare a PR for AppImage, we can start debugging and troubleshooting it together. Making it before the 1.2 release would really be beneficial to the community at large (regardless of the container format).

[tukkek]

AppImage doesn't provide a way to click-and-run the executable without changing execute permission

Neither does .run files. In this sense, you haven't answered my question from a few comments ago asking you to point out if .run has any advantages over AppImages (legacy systems aside, as they're non-critical). You went to some length to prove they're both equivalent solutions and since then we've been doing nothing but discuss technical AppImage advantages. If you (or anyone) cannot provide an argument for .run files over AppImages it seems to me this discussion is then settled.

If someone can prepare a PR for AppImage

@probonopd can you create a pull request adding your recipe into something the project can use? You mentioned in a previous comment that you were willing to make it happen as a Travis artifact build, if there was any interest. I think it's safe to say now that there is a real interest here.

Making it before the 1.2 release would really be beneficial to the community at large (regardless of the container format)

Seems to me @probonopd is quite ready to deliver on that.

[tresf]

If you cannot provide an argument
you haven't answered my question

Since the intent of most recent comments are around "being right" instead of "whats right" by the continual ad homium references, locking. Please pick technology camps elsewhere.

[tresf]

Superseded by #3558 (#3688). Some of the conversation in this thread is around packaging for a specific distribution and many of those issues are still valid, however those tasks are currently maintained by the OS packagers themselves. If this changes, we can open a new issue, or discuss on Discord.