Libretime: Problem: We want to upgrade to Liquidsoap >=1.3.x

[hairmare]

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 https://github.com/LibreTime/libretime/compare/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~Available 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
• Use packages from deb.liquidsoap.info (possibly liquidsoap>=1.4.0)

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]

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]

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]

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 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 https://github.com/LibreTime/libretime/issues/307

[xabispacebiker]

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

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

[Robbt]

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]

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]

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]

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: https://github.com/LibreTime/libretime/compare/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 https://github.com/savonet/ocaml-flac/pull/3 for where I first ran into signs of future incompatibility and more OCaml >=4.02 infos).

[Robbt]

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]

Hey guys,

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

[paddatrapper]

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]

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

[paddatrapper]

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

[hairmare]

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]

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]

Still no so sound in LibreTime. Songs are playing. Shoutcast stream is correctly configured and connected. Everything else seems to be working except sound and I get an "Oops" "Something went wrong" error message when I click on "Status.". Still getting "POSIX" fall-back default" for locale setting no matter how many times I reset the locale to "en_US.utf8".
Added:
LANG=en_US.UTF-8
LC_ALL=en_US.UTF-8
LANGUAGE=en_US.UTF-8

..to /etc/default/locale

[Robbt]

I assume you have rebooted your VPS. This seems like a problem with your VPS and linux config at this point. This also appears unrelated to liquidsoap 1.3, so perhaps there is a better spot to have this conversation.

[AViSource]

Yes. I did reboot the VPS. I believe that there are a couple things going on. I will check with the hosting company about locale setup. But Liquidsoap and the airtime-analyzer.service are not working. Everything else is.

sudo invoke-rc.d airtime-analyzer status
● airtime-analyzer.service
Loaded: not-found (Reason: No such file or directory)
Active: inactive (dead)
invoke-rc.d: initscript airtime-analyzer, action "status" failed.

sudo invoke-rc.d airtime-liquidsoap status
● airtime-liquidsoap.service - Airtime Liquidsoap Service
Loaded: loaded (/etc/systemd/system/airtime-liquidsoap.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Sun 2018-03-04 13:58:55 EST; 3h 46min ago
Main PID: 951 (code=killed, signal=TERM)

Mar 04 13:58:54 radio airtime-liquidsoap[951]: return self._call_chain(args)
Mar 04 13:58:54 radio airtime-liquidsoap[951]: File "/usr/lib/python2.7/urllib2.py", line 407, in _call_chain
Mar 04 13:58:54 radio airtime-liquidsoap[951]: result = func(args)
Mar 04 13:58:54 radio airtime-liquidsoap[951]: File "/usr/lib/python2.7/urllib2.py", line 556, in http_error_default
Mar 04 13:58:54 radio airtime-liquidsoap[951]: raise HTTPError(req.get_full_url(), code, msg, hdrs, fp)
Mar 04 13:58:54 radio airtime-liquidsoap[951]: HTTPError: HTTP Error 500: Internal Server Error
Mar 04 13:58:55 radio systemd[1]: Stopping Airtime Liquidsoap Service...
Mar 04 13:58:55 radio systemd[1]: Stopped Airtime Liquidsoap Service.
Mar 04 14:43:18 radio systemd[1]: Stopped Airtime Liquidsoap Service.
Mar 04 16:41:01 radio systemd[1]: Stopped Airtime Liquidsoap Service.
invoke-rc.d: initscript airtime-liquidsoap, action "status" failed.

[paddatrapper]

So I am slowly working my way through updating the dependencies for liquidsoap, sorry it has been slow going, but I hope to have a new version of liquidsoap uploaded by the end of the month. I'm not sure if it is in time for the Ubuntu 18.04 release though...

[paddatrapper]

Turns out it won't be, but it is coming along

[paddatrapper]

@hairmare, can you assign this to me so I don't have to keep trawling through issues to find it?

[hairmare]

Thanks @Robbt for taking care of assigning.

@paddatrapper I was assuming that you can self assign your own issues since you are a member :confused:

If my assumption is wrong we might want to look into finding a way so Contributors can assign issues. In my case more use of assigning issues would help a lot to get them to the top of my GitHub queue.

[paddatrapper]

@paddatrapper I was assuming that you can self assign your own issues since you are a member confused

Seems not for some reason. I'm not sure what GitHub's permission structure is though for this kind of thing. There should probably be a reviewer/triage role that may work.

Also all dependencies are updated and awaiting upload to Debian unstable. Once that is done, I will be able to finish updating Liquidsoap itself.

[paddatrapper]

Version 1.3.3 is now in Debian unstable o/

[AViSource]

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

[Robbt]

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]

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]

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

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]

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 is relevant to https://github.com/LibreTime/libretime-debian-packaging/issues/3

[AViSource]

Great thanks.

On 11/30/18 3:53 PM, Kyle Robbertze wrote:
>

This is relevant to LibreTime/libretime-debian-packaging#3
https://github.com/LibreTime/libretime-debian-packaging/issues/3

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/LibreTime/libretime/issues/192#issuecomment-443320348,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AhO8T5DmbcvqQAhGSzF2gatB7A7b47i_ks5u0YzJgaJpZM4NLcm4.

>

AVi Source, LLC
AVi Development
Antony Whitehead
www.aviSource.co
914-495-1084 PBX
941-479-0572 What's App
conference: 302-202-1106
access code: 492315

Email Disclosure Statement:
This message and any accompanying documents are intended
for delivery to, and use by, the individual or entity named
above and may contain privileged and/or confidential
information. If you are not the intended recipient, you
are hereby notified that any dissemination, disclosure,
use, distribution, or copying of this information is
prohibited.

[AViSource]

Sounds like an option. Patiently anticipating a movement towards a
configuration that works out of the box.....

Thanks again for keeping me in the information / update loop.

Regards to all,

Tony

On 11/30/18 1:02 PM, Robb wrote:
>

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.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/LibreTime/libretime/issues/192#issuecomment-443269882,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AhO8TxAwGWd6OzQD---lBevCBCnWy81Gks5u0WTAgaJpZM4NLcm4.

>

AVi Source, LLC
AVi Development
Antony Whitehead
www.aviSource.co
914-495-1084 PBX
941-479-0572 What's App
conference: 302-202-1106
access code: 492315

Email Disclosure Statement:
This message and any accompanying documents are intended
for delivery to, and use by, the individual or entity named
above and may contain privileged and/or confidential
information. If you are not the intended recipient, you
are hereby notified that any dissemination, disclosure,
use, distribution, or copying of this information is
prohibited.

[paddatrapper]

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

[virtualfunction]

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]

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

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

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

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

[AViSource]

Hi guys:

My email address has changed as I have changed my domain name. The new
email address is: [email protected]

Trying to add my new address to GitHub but I am not getting the email
verification email from GitHub since I don't have access to my old email
address domain.

Regards,

Tony Whitehead

On 12/1/18 2:44 PM, Kyle Robbertze wrote:
>

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 <‰


You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/LibreTime/libretime/issues/192#issuecomment-443448515,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AhO8TzuWA2IfGHI5LulgKGCnMuiVlH3Wks5u0s4RgaJpZM4NLcm4.

Sent via Migadu.com, world's easiest email hosting

[paddatrapper]

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

[hairmare]

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]

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.

[frecuencialibre]

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]

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]

applied correctly! thanks!

[AViSource]

Good day. I am reaching out to the community after a long time. What is the current status of Liquidsoap 1.3 support or a work around? And what is the easiest way to install the most current LibreTime for someone who is not a developer?

[paddatrapper]

@AViSource download the latest release, apply the patch using the instructions in the release notes and run ./install to install

[AViSource]

@AViSource download the latest release, apply the patch using the instructions in the release notes and run ./install to install

Wow. Thank you so much for your quick reply.

One more question: Do you recommend Ubuntu 16.04? or is 18.04 better?

[paddatrapper]

@AViSource If you want to use Ubuntu 16.04, there is a .deb package that you can just apt install, though 16.04 has an older version of liquidsoap, so it doesn't need the patch.

[paddatrapper]

18.04 also has the old version. Debian Buster and Ubuntu 19.10 should both have Liquidsoap >= 1.3.3 when they release though

[hairmare]

I updated this to reflect that liquidsoap >1.3 exists, it's a tracker issue after all.

I'll create a pr to make liquidsoap >=1.3.2 the new default on master (I'm not sure about the x.z.2 there, I'll update this one I've refreshed my memory).

I'll create/update/add to the docs & release notes for 1.1.1 users after we get 3.0.0-alpha.8 shipped and >=1.3 is the new default on master.

[paddatrapper]

Ubuntu has sync'ed liquidsoap with the version in Debian and it is currently in proposed updates. This means that Ubuntu 20.04 will ship with liquidsoap version 1.3.7. I don't think 19.10 will, as it entered feature freeze on 22 August, but I am not very familiar with their release process.

[paddatrapper]

Update - 19.10 will ship with version 1.3.7

[hairmare]

Awesome news! I'll create a pull request so we can get these change merged once it's clear that new installs will be able to use 19.10. I think this will be towards the end of Sept since we probably won't do any pre-19.10 releases after that point.

[hairmare]

Ubuntu 19.10 has been released. I'll make a PR for the liquidsoap changes once we have a vagrant box for 19.10 (I'm waiting for a bento vagrant box so we can use the same box vendor for all the ubuntu boxes).

[Robbt]

Well Ubuntu 19.10 only has a 9 month support window since it isn't a LTS. 20.04 should have 3 years of support. This is just something to keep in mind. Would there be an easy way for the install script to support both versions for people who don't or can't upgrade to the latest release but want to stay current ?

[hairmare]

We need to get rid of the old 1.1.1 liquidsoap version at some point. They way I see is that people who would like to stay on an LTS can apply a patch before installing or they can install liquidsoap using opam as recommended by upstream.

Waiting for 20.03 would have us deferring the patch for another 6 months forcing everyone using a modern distro to be punished by the need to patch LibreTime.

[Robbt]

Ok, I'm not trying to prevent it from happening, I mean the basic difference is just the liquidsoap.liq file right ? It might make sense to just maintain a legacy version of that file that gets installed if they are using a distro that only has liquidsoap 1.1.1 if they are detected to be on an OS that only supports 1.1.1 - either way as long as it is clear to users who try to install LibreTime on Ubuntu versions before 19.10 since that has been the distro we have pushed people towards most often.

[paddatrapper]

Determining the Liquidsoap script to run happens at run time in python_apps/pypo/liquidsoap. So we can ship both versions of the scripts and selectively run one or the other depending on the version of liquidsoap installed