[RDD] Rivendell 3.0.0beta00 packages for Ubuntu 18.04 LTS (bionic)

[Florent Peyraud]

Hi everybody

I'm Florent, formerly working in Tryphon which used to package Rivendell 
for Debian and Ubuntu, which became a really difficult task due to the 
need of supporting Qt3. Tryphon has closed last year, but here in 
France, I know plenty of users are using Rivendell every day with 
pleasure. They felt quite lonely when we decided to stop Tryphon, so I 
had the idea of a french group of Rivendell Users, involved in 
federating resources, ideas and competencies around the software suite. 
Rivendell-FR was born. It is still very small, but I'm sure it will grow ;)


And to begin with, I'm pleased to announce that Ubuntu packages are 
available for *testing*. Here is the procedure for installation :


1) add the repository

sudo apt-get install apt-transport-https
wget -q -O - https://apt.rivendell-fr.org/release.asc | sudo apt-key add -
echo "deb https://apt-rec.rivendell-fr.org/ bionic main contrib non-free 
beta"|sudo tee /etc/apt/sources.list.d/rivendell-fr.list

sudo apt-get update

2) Install packages

sudo apt-get install rivendell rivendell-server

(don't worry, it downloads half the Internet. That is perfectly *normal* 
:D )


3) reboot in order to take the new group into account

sudo reboot

(it may be sufficient to logout and log in again, please let me know if 
you made the test)


4) restart rivendell service

sudo systemctl restart rivendell

(for a reason I still don't understand, my audio resources were empty if 
I did not restart the service)


At this point, almost everything should be functional.

DISCLAIMER !!!

For the time being, I did NOT compile libhpi, so audio science cards 
will NOT work with Rivendell. But well, it is still in beta. I'll keep 
on working on the debian/Ubuntu packaging now that I have something working.


I hope this will fill a gap. Well, at least on this side of the Atlantic 
see, I'm sure it will ! I hope this will help in testing the beta and 
release the final version. I'll try to produce packages for every 
releases. Please let me know if you have comments or requests concerning 
packaging.


For example, I suggest extracting pypad lib for the main sources, 
because, AFAIK, packaging of python libs on Debian and Ubuntu is much 
easier when it is alone, with its own source package. I'll give a try 
and let you know.


Best regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell 3.0.0beta00 packages for Ubuntu 18.04 LTS (bionic)

[Florent Peyraud]

Hi,
Ubuntu was the first goal as it has an lts supported until 2028. Debian is the 
next step. The packaging should not be so different. I'll give a try and let 
you know. 
Best regards
Florent

Le 21 février 2019 11:53:55 GMT+01:00, "le père Léon"  a 
écrit :
>Le 20/02/2019 à 21:54, Florent Peyraud a écrit :
>> And to begin with, I'm pleased to announce that Ubuntu packages are
>> available for *testing*. Here is the procedure for installation
>Do you plan to make packages for Debian 9/10 ?
>Else I can try, as I managed to install for Deb9..
>
>-- 
>Léon.
>
>___
>Rivendell-dev mailing list
>Rivendell-dev@lists.rivendellaudio.org
>http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell Future

[Florent Peyraud]

Hi Fred and all

Le 24/11/2020 à 15:15, Fred Gleason a écrit :
On Nov 23, 2020, at 20:30, Fernando Della Torre > wrote:


I know it's easy to say and hard to do, but surely Rivendell would 
have a larger visibility if it were packed in 2 or more flavors, like 
RPM and DEB pointing to all dependencies it needs and ready for the 
modern distros, whether Ubuntu, Debian, Mint, Fedora, Centos 8, etc. 
Every time in the past I had to complite from source and every update 
was a kind of a pain.



[...]
This is actually a trope in the wider Linux software ecosystem. It is 
common for large applications there to have two layers of 
‘developers’; a core group (often referred to as ‘upstream’) that does 
the primary application development, and a distribution group (aka 
‘downstream’) that takes the source code output from upstream and 
turns it into installable packages for particular platforms (distros). 
So for example, using the above terminology, I am one of the 'upstream 
developers' for Rivendell; I am also the ‘downstream maintainer' for 
Rivendell's RHEL/CentOS integration. Rivendell has historically had 
other downstream maintainers for other distros —e.g. the Tryphon group 
that for many years maintained a very solid Debian integration. 
Unfortunately, when the Tryphon group disbanded a few years ago, 
support for that integration evaporated.


I would welcome others coming aboard as downstream maintainers for 
their distro of choice. To be a downstream maintainer does not require 
extensive programming ability. What it does need is reasonable system 
administration skills, familiarity with building software from source 
code, and above all a good knowledge of the target platform's software 
packaging and distribution system. I will gladly:


1) Accept PRs from downstream maintainers aimed at making Rivendell 
work better on their platform of choice, and work with their authors 
to get them accepted into the standard Rivendell releases.


2) Provide space on servers in the ‘rivendellaudio.org 
’ domain for hosting packages, 
documentation and other materials for supporting Rivendell on their 
platform of choice.


Anyone up for the challenge?


As a former member (founder) of Tryphon company, I've rebooted the 
Rivendell 3 debian/ubuntu packaging with my new company : Draceo. The 
current status is a functional package set working on Ubuntu 18.04, but 
not on Ubuntu 20.04. The reason is dependencies. Some packages are not 
available anymore on Ubuntu 20.04.


You can find informations on https://apt.rivendell-fr.org/

Disclaimer : The ASI cards are not supported, and the manpages are 
broken. I plan to try sticking as close as possible to the rpm package 
segmentation, but for the time being, there are mostly 3 packages : 
rivendell, rivendell-server and librivendell, the doc package is 
rivendell-doc.



___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell Future

[Florent Peyraud]

OOops, the mail was sent a bit too fast !

Let me add some details ;)

Le 30/11/2020 à 19:22, Florent Peyraud a écrit :


Hi Fred and all

Le 24/11/2020 à 15:15, Fred Gleason a écrit :
On Nov 23, 2020, at 20:30, Fernando Della Torre <mailto:cont...@fdts.com.br>> wrote:


I know it's easy to say and hard to do, but surely Rivendell would 
have a larger visibility if it were packed in 2 or more flavors, 
like RPM and DEB pointing to all dependencies it needs and ready for 
the modern distros, whether Ubuntu, Debian, Mint, Fedora, Centos 8, 
etc. Every time in the past I had to complite from source and every 
update was a kind of a pain.



[...]
This is actually a trope in the wider Linux software ecosystem. It is 
common for large applications there to have two layers of 
‘developers’; a core group (often referred to as ‘upstream’) that 
does the primary application development, and a distribution group 
(aka ‘downstream’) that takes the source code output from upstream 
and turns it into installable packages for particular platforms 
(distros). So for example, using the above terminology, I am one of 
the 'upstream developers' for Rivendell; I am also the ‘downstream 
maintainer' for Rivendell's RHEL/CentOS integration. Rivendell has 
historically had other downstream maintainers for other distros —e.g. 
the Tryphon group that for many years maintained a very solid Debian 
integration. Unfortunately, when the Tryphon group disbanded a few 
years ago, support for that integration evaporated.


I would welcome others coming aboard as downstream maintainers for 
their distro of choice. To be a downstream maintainer does not 
require extensive programming ability. What it does need is 
reasonable system administration skills, familiarity with building 
software from source code, and above all a good knowledge of the 
target platform's software packaging and distribution system. I will 
gladly:


1) Accept PRs from downstream maintainers aimed at making Rivendell 
work better on their platform of choice, and work with their authors 
to get them accepted into the standard Rivendell releases.


2) Provide space on servers in the ‘rivendellaudio.org 
<http://rivendellaudio.org>’ domain for hosting packages, 
documentation and other materials for supporting Rivendell on their 
platform of choice.


Anyone up for the challenge?


As a former member (founder) of Tryphon company, I've rebooted the 
Rivendell 3 debian/ubuntu packaging with my new company : Draceo. The 
current status is a functional package set working on Ubuntu 18.04, 
but not on Ubuntu 20.04. The reason is dependencies. Some packages are 
not available anymore on Ubuntu 20.04.


You can find informations on https://apt.rivendell-fr.org/

Disclaimer : The ASI cards are not supported, and the manpages are 
broken. I plan to try sticking as close as possible to the rpm package 
segmentation, but for the time being, there are mostly 3 packages : 
rivendell, rivendell-server and librivendell, the doc package is 
rivendell-doc.


As the packages are functional, but may require some more tuning to be 
considered as stable, they are in the UNRELEASED distribution.


In order to install a working instance, the procedure is :

wget -q -O - https://apt.rivendell-fr.org/release.asc | sudo apt-key add -
echo "deb [ arch=amd64 ] https://apt.rivendell-fr.org/ UNRELEASED main"|sudo 
tee /etc/apt/sources.list.d/rivendell-fr.list
sudo apt-get update
sudo apt-get install mariadb-server
sudo apt-get install rivendell rivendell-server

Any feedback is welcome to help releasing the official package ! The 
current version is 3.4.1int0. but the 3.4.1int5 is ready and I've a 
working process to package upstream releases quite fast, so I'll try to 
keep as close to latest release as possible.


Best regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell Future

[Florent Peyraud]

Hi Rob

Le 03/12/2020 à 03:56, Rob Landry a écrit :

On Mon, 30 Nov 2020, Florent Peyraud wrote:


Some packages are not available anymore on Ubuntu 20.04.


That troubles me. Since Ubuntu is built on Debian Unstable, that means 
that we are probably no more than two Debian releases away from a time 
when it will no longer be possible to build Rivendell under Debian.


Debian used to be my platform of choice for Rivendell, but lately I've 
been using the CentOS installers. The one recent occasion I had to 
build Rivendell on Debian was on a Raspberry Pi 4, as an experiment. 
Rivendell 2.x would not compile, and while I did get Rivendell 3.x 
installed and running, the process was more complicated and there are 
a lot of new dependencies.


Do I understand correctly that just months after Fred completed the 
long process of porting Rivendell to Qt4, Ubuntu has dropped Qt4?


This is the case :(

Qt4 has been officially dropped in Ubuntu 20.04 LTS in order to 
"encourage" (understand "to force") developers to migrate to Qt6 [1][2]. 
Some PPA exist to install it anyway, but may conflict with some other 
packages. As I wanted to have a stable and maintainable platform with as 
few as possible hacks overriding obsolete packages, I sticked to Ubuntu 
18.04 which will be supported until 2028 (extended LTS). This should let 
us (well.. read "Fred Gleason" ;) ) the time to work on Qt6 migration 
before EoL of 18.04.


Nevertheless, there are also other packages missing, like libmp4v2 IIRC, 
maybe some more... As I needed a solution to upgrade my former customers 
still running 2.10.4 in a country where accentuated characters are so 
common, I focused on a stable transitional solution choosing 18.04. But 
I look forward migrating to 20.04+ ASAP !


Best regards

Florent

[1] 
https://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-20.04-LTS-No-Qt4


[2] https://lists.ubuntu.com/archives/ubuntu-release/2019-August/004800.html

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell Future

[Florent Peyraud]

Hi Fred

Le 01/12/2020 à 17:11, Fred Gleason a écrit :



On Nov 30, 2020, at 14:12, Florent Peyraud <mailto:fpeyr...@rivendell-fr.org>> wrote:


As the packages are functional, but may require some more tuning to 
be considered as stable, they are in the UNRELEASED distribution.


In order to install a working instance, the procedure is :

wget -q -O -https://apt.rivendell-fr.org/release.asc  | sudo apt-key add -
echo "deb [ arch=amd64 ]https://apt.rivendell-fr.org/  UNRELEASED main"|sudo 
tee /etc/apt/sources.list.d/rivendell-fr.list
sudo apt-get update
sudo apt-get install mariadb-server
sudo apt-get install rivendell rivendell-server
This looks really cool. Is there a web page somewhere that contains 
this information? I’m thinking a link on the Rivendell wiki would be 
in order. (I could also simply put all this info into the wiki, but 
then we’ve potential issues with bit-rot when things inevitably change).
There is no such page as for today. I'll do it today or tomorrow and let 
you know, or even change the wiki by myself.



Any feedback is welcome to help releasing the official package ! The 
current version is 3.4.1int0. but the 3.4.1int5 is ready and I've a 
working process to package upstream releases quite fast, so I'll try 
to keep as close to latest release as possible.


FYI: those ‘int’ versions are interim test builds. By all means 
package them, but be aware that they shouldn’t be put into a ‘stable’ 
update stream as they have not been fully tested and could hence hand 
out unpleasant surprises on-air.


Thanks for the advice. I'm looking forward seeing a new stable tag on 
the github repo ;)


Cheers

Florent


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Carts take 5 seconds to start in Main log

[Florent Peyraud]

Hi Rich

Le 30/11/2020 à 17:22, Rich Gattie a écrit :

Greetings list..

I just upgraded the machine I have been running 2.x on to the latest 
v3 of Rivendell. After an annoying issue with the NIC and driver no 
longer in the distro of CentOS 7, I got the machine up and running as 
it was before with one small exception.


While testing the main log, (I use Aux Log 1 for a 24/7 stream), I add 
a cart, hit START, then it takes about 5 seconds to start playing. 
Segues go smoothly between carts, no delay.
There was no issue like this with 2.19.x, and no hardware changes have 
been made to the machine.


I've also hard time migrating a machine from 2.X to 3.X. My primary 
tests on my dev machine were just fine, but when I tried on the target 
machine, the CPU load was huge, and any operation took tens on 
seconds... It looks like your issue.


I've spotted caed taking 100% of a core, on the target machine, compared 
to ~30% of a core on my dev machine. The memory was fine, IOs were quiet 
too. Since then, I'm digging into the source code of caed (mostly in 
cae_alsa.cpp) to try to understand where CPU cycles are vanishing. Using 
valgrind profiler, the mostly called function is AlsaPlayCallback, but 
this is quite obvious and not giving so many clues on what is time 
consuming in there.


Maybe you could verify you CPU load with the "top" oh "htop" commands in 
a terminal in order to see if it points to caed also. What type of CPU 
are you using ?


Until I find a solution to keep caed CPU consumption low on my atom 
machines, I was forced to use a bigger one instead (any old Intel 
Core-i3 I has were just perfect)


If anyone has an idea on why caed is taking so much on the CPU... I've 
tried not to run rdvairplayd but it had no effect


Best regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Touchscreen Monitor

[Florent Peyraud]

Hello

Le 23/11/2020 à 00:49, wa7skg a écrit :
Is anybody using touchscreens with Rivendell? Does it work well? Are 
there any economical touchscreens available these days? Is it really 
worth the extra expense? How is the touchscreen connection handled? 
They used to be via VGA and a serial port, but nothing has serial 
ports anymore. Is it via HDMI and USB?


I confirm VGA/DVI/HDMI + USB for the touch feedback

I used to propose touch screens with rivendell installations, but most 
of the time, it remained unused by people buying it. They prefer 
keyboard and mouse which are less prone to false pointing.


Worse : a customer called me once complaining about rdairplay switching 
to manual mode frequently, and mostly during weekends. After serarching 
the logs and all, there was no clue of any bug or crash. Then I 
remembered the type of touch screen they choose : it was an optical one 
with laser beams coming from screen corners and reflecting on screen 
sides. The good thing with them : they work when wearing gloves, so they 
are widely found in military vehicles. The bad thing : even a fly can 
trigger clicks...


I advised my customer to unplug USB from the screen and rdairplay never 
switched to manual mode "by itself" !


Touch screens remain useful when using rdairplay daily with sound panel.

Cheers

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell v3.5.0

[Florent Peyraud]

Hi Fred and all !

Le 13/12/2020 à 01:35, Fred Gleason a écrit :

On behalf of the entire Rivendell development team, I'm pleased to
announce the availability of the next production release of the next
major version of Rivendell, 3.5.0. Rivendell is a full-featured radio
automation system targeted for use in professional broadcast
environments. It is available under the GNU General Public License
version 2.


The Ubuntu 18.04 package is available on https://apt.rivendell-fr.org on 
both bionic and UNRELEASED distributions (they are actually symlinks)


I've also created a one-line script to install a basic Rivendell 
configuration on a fresh Bionic Beaver minimal install. Please check the 
following link :


https://install.rivendell-fr.org/

Thanks for all the work for this new release. Don't hesitate to give me 
some feedback on the Ubuntu packaging.


Best Regards

Florent Peyraud


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Ubuntu 20.04

[Florent Peyraud]

Hi Nick

Le 19/03/2021 à 03:10, Nick Andre a écrit :
Hey we're getting to update time off of 16.04. Would be nice to get 
sufficient QT4 compiled on 20.04. Anyone made any progress here? Or 
would I be blazing a trail?
We used to do this for Qt3 but this is a lot of work to maintain. There 
are some PPAs around porting Qt4 to Ubuntu 20.04 [1], but the risk is 
that they are not following updates. My opinion is to keep as close as 
possible to distro packages availability. This is why the Rivendell 
packages I propose on https://apt.rivendell-fr.org are built for Ubuntu 
18.04 LTS


May just run 18.04 for now but support there is only 2 more years.


In fact, this LTS will be supported until 2028 by Canonical [2], at 
least for security updates, but this is 7 years ahead. I hope Rivendell 
will be Qt5 enabled before 2028, or even better : Qt6 ready !


Best Regards

Florent

[1] https://ubuntuhandbook.org/index.php/2020/07/install-qt4-ubuntu-20-04/

[2] 
https://www.serverwatch.com/server-news/canonical-extends-ubuntu-18-04-lts-linux-support-to-10-years/




--Nick

On Thu, Oct 1, 2020 at 4:24 PM Luigino Bracci > wrote:


Has you tried with Debian 10?

El vie., 25 de sep. de 2020 a la(s) 08:45, Brian McGlynn
(bmcgl...@geneseemedia.net )
escribió:

Hi,

It won't run on Ubuntu 20.04.  QT4 has been discontinued and
the PPA with QT4 does not have MySQL support.

Brian

*--*
*Brian P. McGlynn*
585-785-4495 x202
bmcgl...@geneseemedia.net 


ᐧ

On Thu, Sep 24, 2020 at 11:53 PM jorge soto
mailto:jsoto3...@gmail.com>> wrote:

Has anybody successfully configured, compiled and
installed latest rivendell on ubuntu 20.04?
If so, care to share how?

Thanks.
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org

http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org

http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org

http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev



___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Fred

[Florent Peyraud]

Hello

I can see commits on qt5 branch of Rivendell 6 days ago

I hope everything is all right.

Fred, can you read us ? Please make a sign !

Best regards

Florent

Le 31/03/2021 à 04:47, Stan Fotinos a écrit :

Hi all

I haven't seen Fred post anything for a while, is anyone in contact 
with him?


Hope all is well!

Stan

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

[RDD] rdcatchd and caed crash when not run as root

[Florent Peyraud]

Hi everyone

I'm currently working on Ubuntu integration of Rivendell, which means 
dealing with systemd, pulseaudio and so on...


In order to make caed use pulse alsa plugin, or even jackd, one solution 
is to log in as root, which is evil.


The other solution would be to run caed as the logged in user. This is 
due to the fact that pulseaudio and jackd daemons are (normally) only 
accessible by the same user as the one that launched them. This is what 
I tried with this procedure :


---8<---

sudo systemctl edit rivendell

[Service]
User=radio

--->8---

then I start Rivendell with `systemctl start rivendell.service`, which 
usually succeed mostly. But caed and/or rdcatchd crash.


I have core dumps but not analyzed it yet. No evidence could be found in 
logs. I'll try to dig deeper and let you know if I can find something 
but I'm interested in your feedback if you can reproduce it on another 
system (centos for instance...).


As far as you know, is there something in rdservice and its children 
which definitely need root rights (shared memory or something like this) ?


Or maybe it could be possible to run rdservice as root, and it could 
launch caed as another user ? I think this was done for pypad components 
at a certain time (this has been rollbacked IIRC)


Thanks for your feedback

Best Regards

Florent


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] rdcatchd and caed crash when not run as root

[Florent Peyraud]

Hi Alejandro

Interesting approach ! Thanks a lot for the sharing :)

Do you use Pulse Audio jack plugin and jackdbus ? Or maybe you just 
blacklist pulse audio, but in this case, how do you handle OS sounds ?


Regards

Florent

Le 11/06/2021 à 10:03, Alejandro olivan Alvarez a écrit :

Hi!

I've been for several weeks now playing with Rivendell (on Debian) too 
... and I faced the same thing as you comment.


I have (IMHO) solved all jackd / root/non-root issues in a way that I 
consider the perfect/definitive one: I run jack IN PROMISCUOUS MODE (a 
mode designed, although rarely used by the average user, precisely to 
allow multi/cross-user client/server inter-operation/sharing, instead 
of jackd's default users compartimentalization. In this mode, as long 
as any user is on a given, same, POSIX group, declared as env variable 
by the user terminal starting Jackd, their jack-client instances are 
user-inter-operable with a common/shared jackd server... ), so, to my 
understanding, rivendell setup is a perfect use-case for a 
promiscuous-mode jackd deployment... here's what I do:


- Create a Systemd unit (jackd.service), that launches jackd in 
promiscuous mode for GID XXX (the unit has environment promiscuous 
variable set to GID XXX)


- Where XXX is rivendell group (I also assign statically rivendell 
user UID XXX)


- To further ensure that promiscuous environment variable present 
system wide, I add it to /etc/environment


- I setup jackd.service unit to be run on boot.. so jackd server, 
becomes a system-wide service, reachable to anyone in GID XXX


- I MODIFY rivendell.service systemd unit to be launched/depend on 
jackd.service unit so it is started AFTER jackd.


- I add root as memeber of group rivendell (GID XXX) , so rivendell 
process, owned by root, can connect to jack service


- I add the normal system user that logs in the terminal, to rivendell 
group (GID XXX), allowing him ant his jackd clients to connect to 
jackd service.



This way, the jackd stuff is totally and completelly user 
transparent/traversal ... rivendell connects to jack just as it 
starts, NO NEED to configure anything, it just works.


Logged user starts qjackctl and, tada!...  it connects automatically 
to the already running jackd server (no need to start jackd from 
qjackctl!)


Any jackd-client application launched by the user, appears in the 
patchbay, and can be connected to/from rivendell (run as root, member 
of XXX)... No problems, no issues, no conflicts, everything JUST WORKS



The only little inconvenience here is that, whenever I update 
rivendell, the rivendell systemd unit is reinstalled, and I have to 
modify it again to make it to 'want' jackd.service.



Hope this helps... If someone is interested on further details on how 
to do this, just let me know!


Best regards.



On 6/9/21 7:45 PM, Florent Peyraud wrote:

Hi everyone

I'm currently working on Ubuntu integration of Rivendell, which means 
dealing with systemd, pulseaudio and so on...


In order to make caed use pulse alsa plugin, or even jackd, one 
solution is to log in as root, which is evil.


The other solution would be to run caed as the logged in user. This 
is due to the fact that pulseaudio and jackd daemons are (normally) 
only accessible by the same user as the one that launched them. This 
is what I tried with this procedure :


---8<---

sudo systemctl edit rivendell

[Service]
User=radio

--->8---

then I start Rivendell with `systemctl start rivendell.service`, 
which usually succeed mostly. But caed and/or rdcatchd crash.


I have core dumps but not analyzed it yet. No evidence could be found 
in logs. I'll try to dig deeper and let you know if I can find 
something but I'm interested in your feedback if you can reproduce it 
on another system (centos for instance...).


As far as you know, is there something in rdservice and its children 
which definitely need root rights (shared memory or something like 
this) ?


Or maybe it could be possible to run rdservice as root, and it could 
launch caed as another user ? I think this was done for pypad 
components at a certain time (this has been rollbacked IIRC)


Thanks for your feedback

Best Regards

Florent


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell v3.6.2

[Florent Peyraud]

Hello

Le 30/07/2021 à 19:33, Fred Gleason a écrit :

On behalf of the entire Rivendell development team, I'm pleased to
announce the availability of the next production release of the next
major version of Rivendell, 3.6.2. Rivendell is a full-featured radio
automation system targeted for use in professional broadcast
environments. It is available under the GNU General Public License
version 2.


[...]


Details and source code are available at
https://github.com/ElvishArtisan/rivendell/releases 
.


Ubuntu bionic (18.04) packages are available on apt.rivendell-fr.org. A 
fully automated one-line procedure is available on 
https://install.rivendell-fr.org


Looking forward to gather your feedback

Best regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

[RDD] Expired certificate on software.paravelsystems.com

[Florent Peyraud]

Hi Fred

It looks like your certificate has expired since September 3rd. This 
causes some trouble (warnings) accessing your websites for downloading 
the good stuff you propose.


Best regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

[RDD] jackd2 and DBUS

[Florent Peyraud]

Hi everyone.

I'm trying to streamline the integration of Rivendell 4 on lubuntu or 
other debian based distros using modern tools such as systemd and DBus. 
Now, qjackctl and the packages jackd2 uses Dbus to launch jack daemon by 
default. This provides some cool features, notably the handshaking with 
pulseaudio in order to release the alsa device from pulse and let jack 
use it instead, and also the automatic connection of pulseaudio into 
jack as a client.


The way qjackctl launches jack is by issuing the "/usr/bin/jackdbus 
auto", then setups and actually starts jack through the DBUS interface 
with /usr/bin/jack_control


I would like to mimic this behavior in order to make rivendell service 
(well... caed) start Jack this way with an external scirpt, but it fails 
when trying to connect jack. The logfile says "Unable to communicate 
with JACK server". Obviously, the actual jack server may take too much 
time to launch and it is not ready when caed tries to connect. DBus 
provides a way to check the status of jack. Maybe just a pause could be 
sufficient to allow jack to start before trying to connect to it.


Would it be possible to take this way of launching jack through DBus 
into account so that it can be started at boot time with caed instead of 
waiting for a user session to begin ?


By the way, I tweaked systemd service for rivendell (sudo systemctl edit 
rivendell) in order to start the daemons with another user (actually the 
user who starts the session afterwards to use Rivendell tools) so that I 
can launch qjackctl or other tools with this user and modify the 
patching of clients without being forced to connect as root, which is 
not recommended on ubuntu/debian. Maybe, it could be useful to be able 
to select the user for each sub-service in rd.conf, and drop privileges 
while starting rivendell service according to this.


Thanks a lot for your answers/ideas. Take care

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] jackd2 and DBUS

[Florent Peyraud]

Hello !

I've just realized I didn't click on "send" button yesterday night, and 
since then, thins may have changed with v4.0.0beta4 ;) Never mind, I 
post it like this, hoping this is still relevant :)


Le 01/12/2021 à 10:43, Alejandro olivan Alvarez a écrit :



On 12/1/21 10:27 AM, Florent Peyraud wrote:

Hi everyone.

I'm trying to streamline the integration of Rivendell 4 on lubuntu or 
other debian based distros using modern tools such as systemd and 
DBus. Now, qjackctl and the packages jackd2 uses Dbus to launch jack 
daemon by default. This provides some cool features, notably the 
handshaking with pulseaudio in order to release the alsa device from 
pulse and let jack use it instead, and also the automatic connection 
of pulseaudio into jack as a client.


The way qjackctl launches jack is by issuing the "/usr/bin/jackdbus 
auto", then setups and actually starts jack through the DBUS 
interface with /usr/bin/jack_control


I would like to mimic this behavior in order to make rivendell 
service (well... caed) start Jack this way with an external scirpt, 
but it fails when trying to connect jack. The logfile says "Unable to 
communicate with JACK server". Obviously, the actual jack server may 
take too much time to launch and it is not ready when caed tries to 
connect. DBus provides a way to check the status of jack. Maybe just 
a pause could be sufficient to allow jack to start before trying to 
connect to it.


Would it be possible to take this way of launching jack through DBus 
into account so that it can be started at boot time with caed instead 
of waiting for a user session to begin ?


By the way, I tweaked systemd service for rivendell (sudo systemctl 
edit rivendell) in order to start the daemons with another user 
(actually the user who starts the session afterwards to use Rivendell 
tools) so that I can launch qjackctl or other tools with this user 
and modify the patching of clients without being forced to connect as 
root, which is not recommended on ubuntu/debian. Maybe, it could be 
useful to be able to select the user for each sub-service in rd.conf, 
and drop privileges while starting rivendell service according to this.


Thanks a lot for your answers/ideas. Take care

Florent


The way I do works just like a charm to me, where everything 
integrates an inter-operates to perfection: I'm using the jackd2 
PROMISCUOUS MODE feature to create a single, system-wide, 
user-interoperable, jackd service, that act as a hub to any jack 
client, of any user (thus Rivendell) on the whole system, allowing 
each user (the workstation user) to manage their GUI clients and/or 
applications using GUI tools and send/get audio to/from any other 
audio clients on the system.


In this mode, Rivendell automatically connects to the system-wide 
jackd server.


In the same way, qjackctl (or any other GUI applications, jack 
manager/client, etc... for instance, I use Ardour as Rivendell's 
mixer, and jamin as DSP) by means of X11/dbus does automatically 
detect and bind to the system-wide, shared, running jackd server... 
automatically.


I had posted specific setup details (Debian) before in this list if 
you're interested on.


Best regards.


Hi Alejandro

Thanks for your answer. I remember this discussion we used to have 
together ;)


I just had a look on it and as you said, you are an advanced user, 
system programmer, and don't rely necessarily on distros sound stack 
(pulse, dbus), which is perfectly fine in your case. The promiscuous 
mode also exist for pulse audio (well, a kind of promiscuous mode) in 
order to have a system wide daemon running.


unfortunately, either promiscuous mode in jack or system-wide daemon in 
pulse-audio are configurations not recommended nor supported. And as I'm 
trying to provide a solution for average users and rivendell 
administrators, who are not necessarily system administrators, I would 
like to avoid as much as possible unsupported or not recommended 
solutions. Moreover, since it deals with shared memory, relaxing 
permissions on such files may introduce security flaws.


By the way, I could not find a way to start Jackd in promiscuous mode 
through dbus. If you have any clue, I would be pleased to test it


Thanks and regards

Florent





___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] jackd2 and DBUS

[Florent Peyraud]

Hi Fred !

Le 02/12/2021 à 22:43, Fred Gleason a écrit :
On Dec 2, 2021, at 08:25, Florent Peyraud <mailto:fpeyr...@rivendell-fr.org>> wrote:


unfortunately, either promiscuous mode in jack or system-wide daemon 
in pulse-audio are configurations not recommended nor supported. And 
as I'm trying to provide a solution for average users and rivendell 
administrators, who are not necessarily system administrators, I 
would like to avoid as much as possible unsupported or not 
recommended solutions. Moreover, since it deals with shared memory, 
relaxing permissions on such files may introduce security flaws.


Well, it all depends on your use case. But first, the low-hanging 
fruit: PulseAudio.


The use case for which PulseAudio was designed is ‘general desktops’ 
—i.e. playing the various beeps, boops and other sound effects 
generated by a GUI in the course of its normal operation when running 
typical ‘office automation’ type applications (web browsers, word 
processors, etc). As such, it has no place on a system designed to 
handle pro audio. It’s one of the first things I typically disable on 
any new Rivendell system.


Well, I agree with you, it depends on the use case : Most of my 
customers are community radio stations. The computers they use are multi 
purpose. They can be used for office suites as well as sound editing 
with audacity as well as browsing the web, or use rdlibrary to encode 
carts. For them, it is quite common to have only the motherboard 
integrated sound card, and it is hard to cope with this device being 
exclusively used by caed with an alsa setup. They DO need to be able to 
listen to songs on the net, then integrate them in Rivendell and set 
markers in rdlibrary, all in the same session. For them, having a sound 
daemon in between allowing concurrent access to the sound device is a 
must. And sometimes, programs does not know how to speak JACK protocol, 
but they know how to speak alsa/pulseaudio language.


I agree, rivendell exclusive access to the sound device is also the way 
I usually sets rdairplay dedicated machines up, but it is less and less 
common for my customers to have this kind of dedicated machine.


As for JACK’s promiscuous mode, I’m not quite sure what you mean by 
calling it ‘unsupported’. It’s present in the stock tarballs and 
binary downloads available at the canonical JACK GitHub site, so it’s 
certainly ’supported’ by the primary JACK developers. Whether its use 
is *appropriate* in a given situation is a matter of professional 
judgement. Does it open new avenues by which a system could be 
compromised in some way? Sure. So does giving a user an account on the 
system. So does turning on the power on the computer in the first 
place. I think the more relevant question to ask is: does it provide 
additional capabilities sufficient to justify the additional risk? The 
standard security principle of ‘least privilege’ holds that a user 
should have no more power on a system than the minimum necessary to do 
their required tasks. Given that Rivendell's previous, 
“non-promiscuous mode” JACK setup required that users run all JACK 
audio applications as ‘root’, I have to imagine that this change makes 
for a vastly improved security posture in general.
Well. "unsupported' may not be the correct term. I've read some ML posts 
talking about this options not being supported, but probably they meant 
it did not represent the most widely used configuration. On the security 
matter, I agree with you, there is a trade-off to find, and after 
looking more closely to the JACK_PROMISCUOUS_SERVER option usage, the 
group limitation could be an acceptable trade-off.
By the way, I could not find a way to start Jackd in promiscuous mode 
through dbus. If you have any clue, I would be pleased to test it


Unfortunately, the only way I’ve found to enable it is to define a 
$JACK_PROMISCUOUS_SERVER variable in the environment and then export 
that to jackd(1) as well as every audio application that will be using 
it. There are a number of drawbacks to this approach, the primary one 
in Rivendell’s case being that there is no easy way to give the 
feature a convenient user-facing ON/OFF switch (with, say, a checkbox 
in RDAdmin). Instead, it’s got to be baked-in to a number of static 
configuration files on the system. There are various values that can 
be given to that environmental variable that influence how it works; 
see the ENVIRONMENT section of the jackd(1) man page for specifics. 
AFAICT, there is no way to enable/disable it via dbus.


I had a look on your commit and saw the nice way you set the variable 
for both the daemon and the user session. It should allow launching jack 
from caed or as a standalone daemon launched on its own (before caed). 
I'll give a try with it. It may be the trade-off between having a full 
DBus dynamically configured system and a strictly static setup. Thanks a 
lot :)


Do you have a target d

Re: [RDD] jackd2 and DBUS

[Florent Peyraud]

Le 03/12/2021 à 15:59, Fred Gleason a écrit :
On Dec 3, 2021, at 05:41, Florent Peyraud <mailto:fpeyr...@rivendell-fr.org>> wrote:



Do you have a target date for the final 4.0.0 release ?


2022Q1 is the current goal, but, in the words of a TV commercial 
widely aired in the US in the 1970s: “We sell no wine before its time.”
It this is the price for the quality... I hope we can help in getting 
this "2022Q1" to be "Early 2022Q1"


Yes, I’m THAT old…  :)


like good wines ;)

Regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Rivendell v3.6.4

[Florent Peyraud]

Hi Fred and everybody

Le 22/02/2022 à 16:56, Fred Gleason a écrit :

On behalf of the entire Rivendell development team, I'm pleased to
announce the availability of the next production release of the next
major version of Rivendell, 3.6.4. Rivendell is a full-featured radio
automation system targeted for use in professional broadcast
environments. It is available under the GNU General Public License
version 2.


Great !

I'm also pleased to announce that v3.6.4 bionic packages are available 
on Rivendell-FR repository :


https://apt.rivendell-fr.org

I've also updated the 1 line installer script available at :

https://install.rivendell-fr.irg

I've refactored the packaging to be as close as possible to the 
packaging scheme of v4.0.0beta3, but using genuine debhelper package 
splitting instead of the very manual file distribution among the 
different package build directories as it is currently done in 
v4.0.0beta3. I borrowed some compile tricks from the "rules" Makefile of 
v4.0.0beta3 in order to improve my own build process so that the 
manpages embedded in the packages I provide are working well now ! 
Thanks a lot ;)


Don't hesitate to send me feedback so that I can make some adjustments 
before sending a pull request for the debian packaging files, which 
should ease package maintainability


Best regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

[RDD] Log refresh when modified from a different machine

[Florent Peyraud]

Hi,

A friend called me to ask why the "refresh log" button doesn't get 
activated after he has modified the log currently playing from another 
machine. When modifying the log on the same machine, it is working as 
expected in rdAirPlay, probably because both rdlogedit and rdairplay are 
connected to the same ripcd.


He is using version 3.6.4 on Linux Mint 19

It's a usecase I've never tested on any version before so I really don't 
know if it was working on former releases. Anyway, I'm wondering which 
mechanism could have been used for this. It would require a pub-sub or 
any kind of broadcast. Nevertheless, the usecase is interesting and may 
be taken into account as an improvement, if it's not a regression ;)


I know there are some messages multicasted on the network, but I'm not 
sure it is used for this purpose. Can anyone tell me what's the purpose 
of these multicast messages ?


Best regards

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

[RDD] Restart subservices (rdcatchd) selectively

[Florent Peyraud]

Hello !

I'm facing some issues with rdcathd putting itself in a state where it 
does not perform scheduled tasks until I restart it. The problem with 
the current implementation of rdservice and systemd, I need to restart 
the complete rivendell service set, which cuts audio during the startup 
and the relaunch of rdairplay. For the time being, I was not able to 
debug rdcatchd when this issue occurs.


Is there a way to restart rdcatchd only with the current implementation ?

A suggest splitting the systemd configuration in different dependent 
units, which would allow a partial restart of rdcatchd, rdpadd, 
rdvairplayd, rdpadengined well, everything except ripcd and caed which 
are strongly shared across other daemons. Another option would be to 
implement a system in rdservice which automatically restarts sub 
services whenever the process exits abnormally.


Any comment on these suggestions ?

Best regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Compatible Soundcards

[Florent Peyraud]

Hi

Le 29/04/2022 à 18:26, Fred Gleason a écrit :

On Apr 29, 2022, at 11:35, Joe Panarello  wrote:

In this vain, Is there any virtual sound card software that will work 
with

Rivendell? I'm fairly sure that there is not any DANTE support for CENTOS
(LINUX) at this moment.


Axia Livewire is the only one that comes to mind right now (which 
Paravel sells as an add-on).


I'm currently testing a wheatnet IP driver for Linux. I think it's in 
beta version right now.


It is functional with Jack as an interface between Rivendell and the 
alsa loopback device used by the driver. It was quite unstable during my 
tests.


I had the opportunity to test it with a Wheatstone Blade V3.

I really look forward some stabilization on the driver because the 
complete wheatnet IP is promising.


I also plan to test open source AES67 drivers, but it relies on a very 
precise PTP network clock source I don't have.


Best Regards

Florent

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] using ssh as desktop helpdesk in trblshooting RD problems

[Florent Peyraud]

Hello
Le 12/11/12 18:52, Fernando Della Torre a écrit :

Hi there!

If you're under ubuntu you can enable the remote desktop (VNC kind) 
and use it through a SSH tunnel.
We in Tryphon are almost using this method, but to avoid having to tune 
our customer's internet modem/router in order to open their SSH port, we 
usually ask them to SSH toward a special 'box' account on our 
infrastructure with a special command line so that all useful ports are 
'tunnelled'. For example from the target rivendellAllbox they could type :


ssh -p 2722 -N -R:localhost:22 -R:localhost:80 
-R5901:localhost:5900 b...@support.tryphon.eu


Doing this, we can log on our support server, then connect locally to 
ports ,  or 5901 to access respectively remote SSH, HTTP or VNC 
servers. And for our headless boxes, they can do the same, even from 
MacOS X or Windows (with putty) with something like :


ssh -p 2722 -N -R:streambox.local:22 -R:streambox.local:80 
b...@support.tryphon.eu


The -N option allows to establish the SSH connection even if the 'box' 
account has /bin/false as shell in the /etc/passwd file


As you may imagine, this method suffers from different problems : one 
could try to squat all ports on our server, For the time being, this has 
never append, but we already think of something to randomize the 
connection port for each connection, or map it to our server only when a 
remote support is scheduled... We are not short of ideas ;)


Hope this can help
Best regards

Florent





Atenciosamente,

*Fernando Della Torre*

Tecnologia da Informação

(: +55 16 8137-1240

(: +55 16 9137-2886

*: _f...@vdit.com.br _

V.D.I.T. Soluções em Virtualização

A utilização deste e-mail não implica em autorização ou outorga de 
poderes para seu usuário praticar qualquer ato em nome das empresas 
citadas, cuja representação considera-se válida se praticada 
exclusivamente por representante legal ou procurador devidamente 
constituído, na forma estabelecida em seu respectivo estatuto ou 
contrato social





2012/11/12 Andy Sayler mailto:a...@wmfo.org>>

Hi Andy,

To the best of my knowledge  SSH is not designed for "Screen
Sharing", and provides no way to do it.

When you connect to a remote machine via SSH, you are creating a
new user session, completely separate from any local user sessions
(or other remote session) already running on the remote machine.
When you use SSH with X server forwarding (the -X option), the
GUIs are actually being generated on your local machine, not
on the remote machine at all (in fact, the remote machine need not
even have X installed). The combination of the fact that each SSH
session is isolated from other user sessions, and the fact that X
over SSH runs locally means that there is no way to "screen share"
using SSH.

Some terminal multiplexers (i.e. GNU Screen) will allow you
to perform terminal "screen sharing" between multiple users, and
you can use this in conjunction with SSH to share your shell, but
I don't believe the sharing capabilities extend to X sessions and
GUIs.

If you want a traditional GUI "screen sharing" experience, you'll
probably need to seek out a program designed for that purpose like
TeamViewer or another remote help/desktop app. If you use Google
Chrome, it also offer a multi-platform remote desktop/sharing app:

https://chrome.google.com/webstore/detail/chrome-remote-desktop/gbchcmhmhahfdphkhkmpfmihenigjmpp.
Some versions of VNC may also support this functionality, but I'm
less familiar with that.

In short, SSH isn't really designed for sharing your session or
screen with local users. You'll have to look for another program
if you want to do that.

Good luck,
Andy
WMFO
a...@wmfo.org 
www.andysayler.com 


On Mon, Nov 12, 2012 at 10:09 AM, VE4PER/ Andy mailto:ve4...@aim.com>> wrote:

Has anyone used ssh connection to actually view a remote
desktop as a
way to see and trblshoot w/s problems?

I use ssh -a -X userid@IPaddress with server running in the
w/s allowing
login. It gives me terminal access in real time and allows me
to run new
instances of window/GUI pgms remotely, however I am not able
to actually
see or share the existing desktop.

Is there something wrong with the syntax I am using to gain remote
desktop GUI access and control to be able to be more
assistance to the
remote operator?

Have used other viewers as well, yet seem only to be able to
run in
console mode or X displays of specific applications rather
than viewing
full desktop?

Thanks

Andy
___
Rivendell-dev mailing list
Rivendell-dev@lists.r

Re: [RDD] E: Unable to locate package rivendell

[Florent Peyraud]

Hi Andy


On 09/05/2018 11:30, Andy Higginson wrote:

Hi,

I'm going to get "flamed" for saying this but I think we need to 
depreciate the Ubuntu install through the Tryphon repository as it's 
now on a very old version of Ubuntu (over 4 years old) which in less 
than 12 months will be EOL.  The last Tryphon repository version is 
based on Rivendell 10.3 and there are no fixes provided for this 
version if security updates in Ubuntu break it.  We also don't know 
how long the repository will still be around for.  We are very 
grateful for all of the work that Alban put into providing this 
repository so Alban, please accept our thanks.


Markus (the original poster?), I think the best advice that you could 
be given is to try the CentOS7 script install of Rivendell.  Once this 
is up and running, you have a stable base on which to play.  I've 
never heard of anything that the Rivendell community has produced 
having adverts so I don't know what you are running.
You are right. The last release on our repositories is pretty 
(understand "fu***ng") old. I'm currently working on packaging for the 
latest 2.19.2, which is already compiling for several ubuntu and 1 
debian distrubutions. As it represents quite a big work since our 
packages contain patches that has not been merged in the upstream 
project (@fred not yet ?) in addition to standard packaging work, I'm 
concentrating on LTS releases and maybe latest releases. A major cause 
of our slowness was the need to repackage Qt3 (which is well 
let's say 'very old') for the new releases, and its dependencies are 
starting to break everywhere. But I found yesterday is some mailing list 
archive that Qt4 is supposed to be working since 2.16. Has it been 
stabilized (I've read that some points were still not really stable and 
some crashes occured at this time) with Qt4?


Moreover, the hpklinux upstream sources has been deeply refactored and 
our packaging scripts must be updated a lot. I saw that Audioscience has 
an Ubuntu PPA providing up-to-date packages, which can be a good 
starting point for Ubuntu, but not recommanded for Debian. I'll see if I 
can repackage starting from the sources files from the PPA.


Moreover, Tryphon SARL (tryphon.eu, our company with Alban) is closing 
soon. This can explain the lack of releases... The repositories and all 
other stuff may be available for some time after the closing, but should 
not been considered as durable. Maybe everything will be transfered to 
another place... In the meantime, even if I'm a Debian/Ubuntu promoter, 
I'll give a try to the CentOS installation of Rivendell in order to have 
an updated opinion on this distribution and to take advantages of the 
new features and bugfixes ;)


I'll keep you all updated as soon as I have some Debian/Ubuntu packages 
ready (my packaging setup is migrating from cowbuilder to docker based 
builder images)


Best regards

Florent
Tryphon CEO


Andy

 On Tue, 08 May 2018 18:50:20 +0100 *Fred Gleason 
* wrote 


On May 8, 2018, at 12:11, IC Radio Tech mailto:icrt...@imperial.ac.uk>> wrote:

I don't recognize the issue you describe, but you can file an
issue on GitHub - you may find the problem will go away on CentOS.


You’d do better to speak to whomever you got the Ubuntu packages
from. GitHub deals with Rivendell code. This sounds like a
packaging problem with Ubuntu.


On 8 May 2018 17:00, MM/BT mailto:mm2...@btinternet.com>> wrote:

I did, in fact, use the Rivendell/Paravel combined download,
but it seemed full of ads, plus a Terminal warning whenever I
made an error that said "this has been reported". Probably a
joke, but disconcerting when you are already out of your depth!


Where exactly did you get this ‘combined download’? It does not
sound like anything that we have ever released.

Cheers!


|--|
| Frederick F. Gleason, Jr. |              Chief Developer        
    |
|                           |              Paravel Systems        
    |
|--|
|         A room without books is like a body without a soul.    
    |
|                                         -- Cicero               
    |
|--|
___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org

http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev





___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivende

Re: [RDD] Tryphon server is dead

[Florent Peyraud]

Hi

One of our servers is actually down since August 1st, as the company is 
progressively closing services.


It means that for a while, resources (apt packages, legacy wiki, maybe 
some other services) are not responding, but I should transfer it on the 
second server soon, until the final closing which should occur end of 
September.


I have a project warming up to durably host these resources and develop 
new ones also. I'll keep you updated as soon as I have good news on it 
and on the interim deb repo.


Best Regards

Florent


On 01/08/2018 12:49, Andy Higginson wrote:

Hi,

It looks like the end of the Tryphon server is finally here.  I'm 
currently not getting any response from tryphon.org or tryphon.eu.


As a community of users, we need to be ready for any questions that 
might be asked here on the list.  What might be useful to know is the 
status of any projects that are on the go to create a new Debian / 
Ubuntu repository.


Lastly I think all that remains is to say a big thanks for everything 
that Alban and the Tryphon team have given to the community.


Andy




___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev

Re: [RDD] Paquetes.

[Florent Peyraud]

Hi

This is great news !

I've set former packages from tryphon up on a new URL :

https://apt.rivendell-fr.org

The former http://debian.tryphon.eu redirects to it

A new key has to be downloaded and trusted. The procedure is written on 
the site above. Please note that it is new HTTPS, so that you will need 
apt-transport-https package on Debian and Ubuntu.


If you are OK to send me the packages, I can test them and if everything 
is fine, I can put them on this repo


Best regards

Florent


On 09/08/2018 21:34, Luigino Bracci wrote:

Hola Juan Carlos,

Ya logré hacer paquetes de Qt3 para Ubuntu 18.04, y también hice 
paquetes de Rivendell 2.7 (que es lo que aún usamos donde trabajo), 
pero no de la última versión 2.19, que es el que se necesita para que 
sea compatible con las versiones de MySQL y MariaDB que vienen con ese 
Ubuntu. Lamentablemente no soy muy ducho empaquetando o haciendo 
repositorios y tengo otras prioridades en el trabajo, pero puedo 
pasártelo por email para ver qué puedes hacer.


In english:

I just finished making Qt3 packages for Ubuntu 18.04, and I also made 
packages of Rivendell 2.7 (the one we still use where I work), but not 
of the latest version 2.19, which is what everyone needs because it's 
the version compatible with latest MySQL / MariaDB coming with Ubuntu 
18.04. Unfortunately, I am not very good at packing / making 
repositories and I have other priorities at my work, but I can pass 
the packages to you by email and you try to make them work.



El 8 de agosto de 2018, 11:29, juan carlos navarro 
hernandezmailto:juancn...@gmail.com>> escribió:


Desde la versión de Debian Jessie no he podido actualizar a la
ultima versión de Rivendell, ni tampoco instalarlo en versiones
mas actuales como Ubuntu 18.04 o Debian 9.

¿alguien sabe como hacer esto por favor y que me pueda guiar en el
proceso?

-- 
Juan Carlos Navarro Hernandez.

http://tecnolibre.com.ve/
juancn...@joindiaspora.com 
Twitter: @juancnh80

___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org

http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev





___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev


___
Rivendell-dev mailing list
Rivendell-dev@lists.rivendellaudio.org
http://caspian.paravelsystems.com/mailman/listinfo/rivendell-dev