New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Problem: We want to upgrade to Liquidsoap 1.3.x #192

Open
hairmare opened this Issue Apr 28, 2017 · 47 comments

Comments

Projects
None yet
9 participants
@hairmare
Copy link
Member

hairmare commented Apr 28, 2017

Issue

The thing is, liquidsoap 1.3.0 was recently released and it contains some fixes that are highly relevant to us. There were changes to liquidsoap that need adopting our code to in a way that breaks with the liquidsoap <1.3.0 (like the 1.1.1 we currently have on Debian). I did the required changes on master...radiorabe:feature/liquidsoap-1.3.0 and they are rather minimal but break badly with older liquidsoap releases.

See below for how to patch your install to use 1.3.x now.

Proposed Solutions

The liquidsoap package that was previously maintained by @toots on Debian but has been orphaned in favor of opam so we need to consider a couple of options going forward.

  • Take over the packaging torch and bring the packages up to date (I think this means removing the modularity and making one large binary)
  • Try submitting an NMU (non maintainer update) against the packages in the hopes that it can get bumped and stay unmaintained for a while (same as option 1 but doable without a Debian contributor on board)
  • Offer our own packages based on the NMU or even completely separate from Debian and Ubuntu (ie. built on build.opensuse.org)
  • Change our docs and the install script to install liquidsoap from opam

Details for opam Solution

Since the last one in this list is recommended in the liquidsoap docs I'm documenting what is needed to get it working on the Ubuntu Trusty vagrant box (I started running these as root, the user to use is mostly noted where a switch is needed).

# remove distro liquidsoap
apt-get remove liquidsoap
# prepare system for opam install
add-apt-repository ppa:avsm/ppa
apt-get update

# install system packages like opam (the make tools are for the 1.3.0+scm install below)
apt-get install ocaml ocaml-native-compilers camlp4-extra opam autotools-dev automake
mkdir /usr/local/opam
chown liquidsoap:liquidsoap /usr/local/opam /usr/share/liquidsoap/

# we need to switch to the liquidsoap, some things do not like being installed as root
usermod -s /bin/bash liquidsoap
# switch to now active liquidsoap user
sudo --login -u liquidsoap
# run as liquidsoap user
opam init --root=/usr/local/opam

# To setup the opam/ocaml you initialized in the current shell, you need to run:
# Until you install a profile you need to do this each time you want liquidsoap on the $PATH
eval `opam config env --root=/usr/local/opam`

# I installed the deps as root before re-installing as user liquidsoap
# run this as root after running an additional eval `opam config env --root=/usr/local/opam`
opam depext alsa cry fdkaac lame liquidsoap mad opus taglib vorbis

# install liquidsoap and deps we need (run this as user liquidsoap again)
# run the git instruction instead of this for now (or re-install from git after pinning below)
opam install alsa cry fdkaac lame liquidsoap mad opus taglib vorbis    

# run this as root to make liquidsoap your default on the whole system (extremely hacky)
echo "eval \`opam config env --root=/usr/local/opam\`" > /etc/profile.d/liquidsoap-opam.sh
ln -s /usr/local/opam/system/bin/liquidsoap /usr/bin/liquidsoap

This gives us liquidsoap 1.2.1 and will also work for 1.3.0 once it is available from opam. The above installs the current 1.3.x version of liquidsoap. Switching to the git install that might have additional patches works as follows.

# as long as opam does not have 1.3.0 we switch back to the liquidsoap user to install from git:
opam install alsa cry fdkaac lame mad opus taglib vorbis
sudo --login -u liquidsoap
git clone https://github.com/savonet/liquidsoap.git
cd liquidsoap
git submodule init
git submodule update
opam pin add liquidsoap .

Having this the vagrant boxes for Ubuntu and Debian might be an option as they are geared toward developers anyway. I'm not convinced that it's something we can support for users though. CentOS is already on 1.3.0. I believe I'm the only user of LibreTime on CentOS at the moment (please correct me if I'm wrong) so I'll just live with applying feature/liquidsoap-1.3.0 manually or during packaging until we can figure out how to best get the branch merged.

I think most of this has previously been discussed (ie. in the debian packaging context) and this issue was created to have a tracker issue for everything regarding the liquidsoap bump.

Workarounds

Should you want to test liquidsoap 1.3.1 you can apply this patch manually. Depending on how you got your copy of LibreTime there are different ways to do so.

You need to apply the patch before running the installer (or you need to rerun it after applying the patch).

tarball install

An up to date patch is available through GitHub and can be applied to an unpacked tarball as follows.

cd libretime-3.0.0-alpha.2/
curl -L https://github.com/LibreTime/libretime/compare/master...radiorabe:feature/liquidsoap-1.3.0.patch | patch -p1

For LibreTime >=3.0.0-alpha.7

cd libretime-3.0.0-alpha.7/
curl -L https://github.com/LibreTime/libretime/compare/master...radiorabe:feature/liquidsoap-1.3-for-3.0.0-alpha.7.patch | patch -p1

git working copy

To merge the liquidsoap-1.3.0 branch to the local working copy you can run the following. You should probably create a new branch based on master before you do this. If you merge to your local master your working copy might need some work during upgrades going forward.

cd libretime/
git remote add radiorabe https://github.com/radiorabe/libretime.git
git pull radiorabe feature/liquidsoap-1.3.0
# or for LibreTime >=7.0.0-alpha.7
git pull radiorabe feature/liquidsoap-1.3-for-3.0.0-alpha.7
@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Apr 28, 2017

Hmm, this is a big decision. The opam path seems like the one that is both easiest and most supported, ie the debian maintainer deferred to it. The drawbacks are I think based upon our previous conversation that it will make the installation process more complicated, burdensome, brittle and difficult to do without Internet access.

The alternative though of interjecting ourselves into the Debian project seems like it will be a lot more difficult. If someone ie even me does go through the process of taking over the packages for debian this would be great, but this isn't something that we should count on. This leaves the other two options.

I'd prefer a combination of the other two options. I'd say for now we should go ahead with the testing and implementing the opam install. If and when we get to the point of providing debian packages again we can then either package it ourselves and/or perhaps at this point we will be able to make headway with getting the updated packages back into Debian again.

But it does seem like the most expedient path is to add another layer of OPAM complexity to the installation process. I'd like to get to building packages and making things easier but I think we should be doing the easy upgrades like this.

Also sorry I have been away from github, been finishing finals for school and all around super busy to the point of not having a few spare moments to get on here and merge commits.

@hairmare

This comment has been minimized.

Copy link
Member Author

hairmare commented Apr 29, 2017

I'm thinking opam on vagrant and proper NMU builds for other environments. It looks like we'll need proper docs on the opam process in any case (these can be mostly pointers to http://liquidsoap.fm/download.html and https://opam.ocaml.org/doc/Install.html).

Good luck with your finals!

@toots

This comment has been minimized.

Copy link

toots commented May 3, 2017

Hey guys. Let me know if we can help. I definitely do not wish to package for Debian. My time is limited and, from the developper point of view, opam packaging is near, quick to deploy on a lot of OSes and handles external dependencies..

One thing that could be considered, though, is a quick packaging based on a build using opam. For instance, it is fairly easy to build a static binary using opam on alpine (possibly with docker) and then distributing this on all linux platforms.

@xabispacebiker

This comment has been minimized.

Copy link
Contributor

xabispacebiker commented Sep 26, 2017

This is awesome! thanks @hairmare for your help. I have spent the whole afternoon but I finally ended up with a working Libretime + liquidsoap 1.3. But now I have a problem. In a first place it seemed to work but all of a sudden it started to stream silence, although when there was a scheduled show with content. I have opened a new issue #307

@xabispacebiker

This comment has been minimized.

Copy link
Contributor

xabispacebiker commented Sep 28, 2017

@hairmare, your solution is awesome, big thanks! But please add alsa support. I successfully added it by opam install alsa, although I got some weird errors saying it could not download the sources then I had to force the download with the root user and place the alsa.tar.gz file in the right path so that opam finds it and does not try to download it again.

So to say.. when installing liquidsoap this way, I noticed that the configure command line reads "--with-user:dummy --with-group:dummy", I think this has been the culprit of my permission troubles.. The changes we made to the pull request seems to solve it, but today I did all the steps again + the alsa support and at the end:

./configure --prefix /usr/local/opam/system --sbindir=/usr/local/opam/system/lib/liquidsoap/sbin --libexecdir=/usr/local/opam/system/lib/liquidsoap/libexec --sysconfdir=/usr/local/opam/system/lib/liquidsoap/etc --sharedstatedir=/usr/local/opam/system/lib/liquidsoap/com --localstatedir=/usr/local/opam/system/lib/liquidsoap/var --libdir=/usr/local/opam/system/lib/liquidsoap/lib --includedir=/usr/local/opam/system/lib/liquidsoap/include --datarootdir=/usr/local/opam/system/lib/liquidsoap/share --disable-graphics --with-user=liquidsoap --with-group=liquidsoap

These steps somehow solved all my troubles and now it seems to be working fine.. I will keep this server on test and see what happens.

@hairmare

This comment has been minimized.

Copy link
Member Author

hairmare commented Sep 29, 2017

I updated the example in the issue to install alsa. Thanks for the input. Not sure what's with the dummy user though.

@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Dec 12, 2017

So we haven't made any progress on this but the reoccuring issues with debian mp3 imports see #380 are making this a more pressing issue. It may make sense to simply move forward with the opam install for the install script.

If and when we decide to build deb packages for LibreTime then we can manually do that and support them but as long as we are approaching everything from the hacky CLI install script we might as well just do a opam install in my opinion. I'm going to play around with modifying the install script to see if I can get this working without too much effort based upon the above script.

@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Dec 14, 2017

So testing liquidsoap 1.3 on debian I've ran into a few issues.

For instance under the
def stopped()
"stopped" == list.hd(server.execute("#{id}.status"))

needs to be
"stopped" == list.hd(default="",server.execute("#{id}.status"))

There are alot of others that have the same issue.
I fixed them and I'm getting stuck at line 44 of ls_script.liq
the value has type (default:int)->int
(default:int)->int
but it should be of subtype
something that is an orderable type

Not sure what to change here.

@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Dec 14, 2017

Ok, so I figured it out, for everything that had list.nth and was an int, I needed to add default=0 as the 3rd parameter and it was able to process and work.

I first ran into an issue with %ifencoder that I needed to fix...so I commented out the %ifencoder aac portion of Liquidsoap and I was able to get it to parse the script and find the bugs I mentioned above.

The issue I think is that if we push a fix for liquidsoap 1.3 to our liquidsoap scripts my guess is that they won't work with liquidsoap 1.1

But I was able to get the stream running, after modifying the scripts so that is a positive. I should be more thorough about this but I figure it is better to document the fix haphazardly than to to do nothing and have someone else run into this problem.

@hairmare

This comment has been minimized.

Copy link
Member Author

hairmare commented Dec 19, 2017

The issue I think is that if we push a fix for liquidsoap 1.3 to our liquidsoap scripts my guess is that they won't work with liquidsoap 1.1

Absolutely, that is why this is an open issue. You'll find my original fix for 1.3.0 in the patch linked at the top of the issue: master...radiorabe:feature/liquidsoap-1.3.0, it is currently tested with versions up to 1.3.2.

I've been using 1.3.x on CentOS for a while now and my RPM packages use this patch during their build process.

I was hoping that we wouldn't have to go down the opam route on Debian but all signs point to it. This makes having a working build env on the install machine a must have and liquidsoap currently (1.3.3) needs at least OCaml 4.02 to build.

On Debian OCaml 4.02 is only in 9/stretch so we would probably need deprecate 8/jessie completely to get this switch done. Ubuntu started having OCaml in 16.04/xenial so the build will also fail with 14.04/trusty.

Most likely CentOS will also have this issue soonish as liquidsoap has started switching to a new version of the OCaml (see savonet/ocaml-flac#3 for where I first ran into signs of future incompatibility and more OCaml >=4.02 infos).

@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Dec 21, 2017

Ok, so if we were to proceed down the path of opam based install it would make sense to only start supporting this option for Debian 9 and later & Ubuntu 16.04 and later.

We could offer the previous deb based install for older versions in the meantime.

I don't know that anyone has had liquidsoap issues with Debian Jessie and I'm still not sure what is causing the failure of mp3 files on certain Debian Stretch installers, but the only sure fix/workaround I'm aware of is compiling liquidsoap from opam. So we should try to figure this out as it would allow us to avoid prioritizing this upgrade.

I'd be happy to stay with the older version of Liquidsoap if we are able to fix the liquidsoap issue in the meantime as I'm not aware of what the benefits of switching to Liquidsoap 1.3 are at this point. I looked at the features and I don't think we need any of them unless we were to develop new features.

@toots

This comment has been minimized.

Copy link

toots commented Dec 23, 2017

Hey guys,

Would a build script that creates a statically linked stand alone build of liquidsoap help?

@paddatrapper

This comment has been minimized.

Copy link
Contributor

paddatrapper commented Jan 26, 2018

Seeing as I am already doing much of the Debian packaging work. Shall I take over liquidsoap packaging? I am a Debian Maintainer, which does make things a little easier, and I expect to have the time to maintain the package

@toots

This comment has been minimized.

Copy link

toots commented Jan 26, 2018

That would be awesome. I'm cool to give a hand on the liquidsoap side.

@paddatrapper

This comment has been minimized.

Copy link
Contributor

paddatrapper commented Jan 30, 2018

I've requested access to the salsa Ocaml group. Once that is approved, I will start packaging the new version

@hairmare

This comment has been minimized.

Copy link
Member Author

hairmare commented Feb 2, 2018

here is a list of all the build deps that I needed to package for a working liquidsoap 1.3.2. Maybe the list helps pin down any toolchain deps that also need packaging or updating for the build to succeed.

Thanks heaps for all of your hard work!

@paddatrapper

This comment has been minimized.

Copy link
Contributor

paddatrapper commented Feb 3, 2018

Thanks that helps a lot. As the last release was in 2014 there's a fair amount of work required to get the new release working properly

@AViSource

This comment has been minimized.

Copy link

AViSource commented Aug 15, 2018

This is great news... I am going to do a fresh install on a new VPS server and install it.

@hairmare hairmare changed the title Problem: We want to upgrade to Liquidsoap 1.3.0 Problem: We want to upgrade to Liquidsoap 1.3.x Nov 24, 2018

@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Nov 30, 2018

So I think that we need to determine a way of testing liquidsoap 1.3 vs 1.1.1 and comparing how they interact with our software to determine if A they are compatible (they aren't see required changes above) and B if 1.3 fixes some bugs that we have ran into when doing RT scheduling and changes of tracks more on the fly.

I know @ned-kelly is currently testing 1.3 to see if he finds it more stable but until we determine the reproducible causes of some of these bugs we can't determine whether 1.3 fixes them.

We also have the issue that the current versions of Debian seem to have broken liquidsoap packages see #352 whereas Ubuntu packages on versions >= 14.04 work out of the box and Debian 10 will have a php version that is incompatible with Zend 1 (#580)

So if we want to start supporting 1.3 we will need to start at least providing different liquidsoap config files with these changes and figuring out how to get our installer to use the right versions when a distro with 1.3 is used. But until we can figure a workaround for the Php problem it's kind of a moot point and will require a fair amount of hacking. According to @paddatrapper backporting Liquidsoap 1.3 isn't really an option so the only feasible way to support it is with opan for any distros other than those based upon what will be Debian 10. Probably Ubuntu 19.04 will be based on this and the next LTS will be 20.04. So unless we figure out a way of backporting a debian package it is unlikely that we can require 1.3 without either supporting OPAN or basing our release on the forthcoming Debian 10 and excluding Ubuntu until 2020 as it doesn't make sense to have our users run on anything other than a LTS version of Ubuntu.

@virtualfunction

This comment has been minimized.

Copy link

virtualfunction commented Nov 30, 2018

Because of all the ocaml deps that seem to be a little dated in Ubuntu (I believe Debain testing has recently caught up if my memory serves me) does it make sense to investigate snap or flatpak packages so package maintainers aren't held down to the outdated deps.

@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Nov 30, 2018

@virtualfunction good point. I forgot about that option because I haven't fully investigated it and nobody has stepped forward with the knowledge and interest in building snap or flatpak packages. Is this something you have much experience with ?

@virtualfunction

This comment has been minimized.

Copy link

virtualfunction commented Nov 30, 2018

I merely know of its existence, nothing more. But do think it solves our woes if there is someone who has the skillset and time

@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Nov 30, 2018

I just did a little research and I think for our purposes docker images might make the most sense as a nice compromise that allow us to have a configuration that works out of the box for people and can be easily updated because basically LibreTime is developed with the assumption that you will be running it on a dedicated host vs. it being an application running alongside other instances. I think that flatpak & snap might be geared more towards allowing certain apps to coexist with other apps w/o causing versioning conflicts whereas we don't recommend people run LT unless it is on a dedicated host or VPS because it depends upon so many different system-wide services and configurations. But thanks for the recommendation.

@paddatrapper

This comment has been minimized.

Copy link
Contributor

paddatrapper commented Nov 30, 2018

@AViSource

This comment has been minimized.

Copy link

AViSource commented Nov 30, 2018

@AViSource

This comment has been minimized.

Copy link

AViSource commented Nov 30, 2018

@paddatrapper

This comment has been minimized.

Copy link
Contributor

paddatrapper commented Nov 30, 2018

I've added to the wiki tracking distros with working PHP, Liquidsoap and Silan combinations. In Debian/Ubuntu only 16.04 works...

@virtualfunction

This comment has been minimized.

Copy link

virtualfunction commented Nov 30, 2018

Yea, I would have used docker but there are use cases where it would be good to have direct access to sound hardware or via JACK (I guess the socket / device can be mapped to the host though)

@Robbt

This comment has been minimized.

Copy link
Member

Robbt commented Nov 30, 2018

@virtualfunction I think that @ned-kelly is planning on integrating jack with his multi-container-docker setup. For the single container mapping the device out directly is the route I'd probably pursue.

@ned-kelly

This comment has been minimized.

Copy link
Member

ned-kelly commented Dec 1, 2018

@Robbt @virtualfunction - The latest build on docker hub is now running and stable with Silan 0.4 and Liquidsoap 1.3.4 (September 2018 Release) -- It does not yet include auto-import functionality @Robbt wrote - That's the next thing on my list for Monday when I'm back working on this again...

@virtualfunction Jack is a harder one to tackle - Probably a day or two of wiring things up - I'm planning on using Jack for "dead-air" detection so we can drop in a pre-defined playlist on libretime if there's more than x seconds of dead air...

The other thing that's still a WIP and currently a higher priority is integrating "fallback auto-dj" in the Icecast config in the event that Libretime goes offline / the container is rebooted or whatever... The main priority I have here is to ensure that clients connected to the stream are never dropped (Because I've got several hundred Sonos's playing the stream in various venues - and it's a pain if they all need to be manually restarted).

Will keep you posted: https://hub.docker.com/r/bushrangers/ubuntu-multicontainer-libretime/

(Update - sorry to hijack the thread - Probably best we keep the general chat on Slack/Discourse)

@paddatrapper

This comment has been minimized.

Copy link
Contributor

paddatrapper commented Dec 1, 2018

Good news! I should be able to upload a fix for liquidsoap 1.1.1 to Debian stable. Essentially this will be the same fix as in Ubuntu, meaning that Debian Stable (with backported Silan) should work with LibreTime 🎉

Waiting for approval: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=916650

@AViSource

This comment was marked as off-topic.

Copy link

AViSource commented Jan 1, 2019

@paddatrapper

This comment has been minimized.

Copy link
Contributor

paddatrapper commented Jan 21, 2019

Are the fixes for liquidsoap 1.3.x compatible with earlier versions?

@hairmare

This comment has been minimized.

Copy link
Member Author

hairmare commented Jan 21, 2019

They only work for liquidsoap >=1.3.0 as there are some bc breaking changes in the original 1.3. I never used liquidsoap 1.2.* but I'm sure that 1.1.* won't work with these changes.

If we need to support multiple versions (ie. 1.1.* and 1.3.*) in parallel we could offer multiple versions of the script and select the right one based on the actual liquidsoap version. I was hoping to figure out if we can get around maintaining multiple versions once liquidsoap packaging is up and running again.

Right now it looks like it might make sense to switch to a 1.3.* version of liquidsoap at the same time we deprecate systems that still come with an older release.

@paddatrapper

This comment has been minimized.

Copy link
Contributor

paddatrapper commented Jan 21, 2019

Unfortunately 16.04 and 18.04 have liquidsoap 1.1.1. The next Ubuntu LTS (20.04) will be the first LTS to ship 1.3.x (as I need to manually request they resync with Debian, which I will do in about a month). So (unless we deprecate 18.04 early and have no Ubuntu LTS support for a year), we will only be able to move to 1.3.x in April/May 2020 at the earliest.

@paddatrapper paddatrapper removed their assignment Jan 24, 2019

@frecuencialibre

This comment has been minimized.

Copy link
Contributor

frecuencialibre commented Feb 1, 2019

i think the patch referenced in the release notes needs to be updated following the most recent aac work. i'm getting this error which is unfortunately blocking instance creation using the @ned-kelly 's multicontainer docker setup:

$ curl -L https://github.com/LibreTime/libretime/compare/master...radiorabe:feature/liquidsoap-1.3.0.patch | patch -p1

The next patch would delete the file python_apps/pypo/liquidsoap/aac.liq,
which does not exist!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
The next patch would delete the file python_apps/pypo/liquidsoap/aacplus.liq,
which does not exist!  Assume -R? [n] 
Apply anyway? [n] 
Skipping patch.
1 out of 1 hunk ignored
patching file python_apps/pypo/liquidsoap/ls_lib.liq
Hunk #1 FAILED at 152.
Hunk #2 FAILED at 203.
2 out of 2 hunks FAILED -- saving rejects to file python_apps/pypo/liquidsoap/ls_lib.liq.rej
patching file python_apps/pypo/liquidsoap/ls_lib.liq
Hunk #1 succeeded at 266 (offset 7 lines).
Hunk #2 succeeded at 321 (offset 7 lines).
Hunk #3 succeeded at 374 (offset 7 lines).
patching file python_apps/pypo/liquidsoap/ls_script.liq
patching file python_apps/pypo/liquidsoap/liquidsoap_auth.py
patching file python_apps/pypo/liquidsoap/ls_script.liq
patching file python_apps/pypo/liquidsoap/ls_script.liq

also, should we decide to support multiple liquidsoap versions, (possibly in the installer?) would this become relevant to #682?

@hairmare

This comment has been minimized.

Copy link
Member Author

hairmare commented Feb 1, 2019

I updated the original issue with a patch specific to current master/>=3.0.0-alpha.7:

curl -L https://github.com/LibreTime/libretime/compare/master...radiorabe:feature/liquidsoap-1.3-for-3.0.0-alpha.7.patch | patch -p1
@frecuencialibre

This comment has been minimized.

Copy link
Contributor

frecuencialibre commented Feb 1, 2019

applied correctly! thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment