So, you want to develop gutenbach, eh? Good! Gutenbach is a distributed music player built on top of CUPs. It essentially enables anybody with access to it to play music from their own computer -- all they have to do is "print" to the Gutenbach instance as they would any other document! The current repositories for various Gutenbach features are: - gutenbach - gutenbach-queue - gutenbach-remctl - gutenbach-rhythmbox-plugin - gutenbach-itunes-plugin - gutenbach-web All of these are located on GitHub: http://github.com/search?langOverride=&q=gutenbach&repo=&start_value=1&type=Repositories Additionally, see README.old for how Gutenbach /used/ to be installed. This can sometimes offer insight into how to fix things that are broken. Questions or comments should be directed at gutenbach@mit.edu NOTES: - If you keep getting zephyrs with the following errors: Playback completed with the following errors: bt_audio_service_open: connect() failed: Connection refused (111) bt_audio_service_open: connect() failed: Connection refused (111) bt_audio_service_open: connect() failed: Connection refused (111) This is because you have alsa configured for bluetooth, but bluetooth is not enabled. You should either enable bluetooth, or uninstall the bluez-alsa package. - To print to a machine without keytabs, you need to do: lpr -Pprintername -Hhostname $file The old `lpr -Pprintername@hostname $file` syntax will no longer work. TODO: - include mixer and channel in debconf, or even better, move it to gutenbach-remctl and implement debconf in that package - the filter should die and send an error message if it can't find the config file, not use defaults - this should really not conflict with pulse (the biggest problem at the moment is that pulse will spew a bunch of errors like "Home directory /var/spool/cups/tmp not ours." I can't figure out how to get rid of them, but they're really annoying. As long as pulse is in system mode, things seem to work otherwise.) - finish the move to CUPS! * the CUPS daemon processes do not inherit groups from the lp user (so, for example, even if we add 'lp' to 'audio', the process will not be running in group 'audio'). For the time being, I've set the CUPS daemon to always run under group 'audio', but there should really be a better solution. * lprm does not remove jobs -- we should maybe leave a pid file and kill the mplayer process if someone kills the job * you can currently play files locally, but not remotely -- why?