This removes most of the legacy upstream config madness by not using
weird config files spread all over the place.
This isn't the solution to other config reading fragility issues, but
it does move the whole config back to the central airtime.conf file.
This is a workaround to make updating easier for folks who do not re-install. A proper solution would get rid of most of the Config class and use something based on Zend_Config_Ini instead. It would also have some sensible defaults in the code and nor error when new values get added.
This is part 2 of fixing ecasound recordings from line-in. Part 1 restored the User-Interface, part 2 takes care of getting to the point where ecasound gets started, records something and uploads it through rest when done. Part 3 will take care of making sure that the recorded file is mapped to the show and not just stored as a new track.
I refactored api_clients to not use urllib2 for posting multipart data since I was loosing my sanity over it and requests seems to have a modern approach to doing this compared to what api_clients was previously doing.
This makes LibreTime check its version against github releases and lets the user know when to update. It uses the red exclamation point when there is a patch release or if LibreTime is more than one major release ahead. The orange icon is used when LibreTime is on a git install, a single major update is available, or a pre-release version is installed. The green update icon gets used to signify that a new minor release is available. Finally the green checkmark will be used when you are on a stable release.
This is to get the help section to look better and point to somewhere users can find us. It also takes care of /dashboard/about and maybe more.
Some of the links I'm adding are 404 as we have yet to write them, I'd rather link something we have under our control rather than legacy transifex or others.
This is the results of sed -i -e 's|/etc/airtime-saas/|/etc/airtime/|' `grep -irl 'airtime-saas' airtime_mvc/ python_apps/` :P
It might need more testing, the airtime-saas part never really made sense, zf1 has environments for that, ie you would create a saas env based on production for instance.
I beleive legacy upstream was using this to share configuration between customers (ie. analyser runs only once and writes to a shared S3 bucket). I assume they mount the airtime-saas folder onto individual customers instances with a global config. Like I said, I don't feel that this makes sense since all it does is make hacking at the configs in airtime-saas a bit easier. A serious SaaS operation should be using something like puppet or ansible to achieve this.
Zachary Klosko
Kyle Robbertze
robbt
farggus
Codenift
Kyle Robbertze
Lucas Bickel
Lucas Bickel
Xabi Spacebiker
Robb Ebright