about summary refs log tree commit diff
path: root/pkgs/applications/audio/pianobar
Commit message (Collapse)AuthorAge
* treewide: use ffmpeg_3 explicitly if not wanted otherwiseDoron Behar2020-06-12
| | | | | | After making `ffmpeg` point to the latest `ffmpeg_4`, all packages that used `ffmpeg` without requiring a specific version now use ffmpeg_3 explicitly so they shouldn't change.
* pianobar: 2019.02.14 -> 2020.04.05R. RyanTM2020-04-12
|
* pianobar: *Flags are listsRobin Gloster2019-12-30
|
* pianobar: enable on darwinMario Rodas2019-09-17
|
* pianobar: 2018.06.22 -> 2019.02.14 (#58750)R. RyanTM2019-04-07
| | | | | | Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/pianobar/versions
* pianobar: 2016.06.02 -> 2018.06.22 (#45913)Ricardo M. Correia2018-09-01
|
* rm maintainer eduarrrd from packages, no activity > yearAnton-Latukha2018-07-22
|
* pkgs/*: remove unreferenced function argumentsvolth2018-07-21
|
* treewide: Manual fix more pkg-config build-inputsJohn Ericson2017-09-21
|
* pkgs: refactor needless quoting of homepage meta attribute (#27809)Silvan Mosberger2017-08-01
| | | | | | | | | | | | * pkgs: refactor needless quoting of homepage meta attribute A lot of packages are needlessly quoting the homepage meta attribute (about 1400, 22%), this commit refactors all of those instances. * pkgs: Fixing some links that were wrongfully unquoted in the previous commit * Fixed some instances
* pianobar: 2015.11.22 -> 2016.06.02Kranium Gikos Mendoza2016-06-22
|
* pianobar: 2014.09.28 -> 2015.11.22Eduard Bachmakov2016-01-14
|
* Turned some meta.maintainers into listsPascal Wittmann2015-05-14
|
* pianobar: update to pianobar-2014.09.28Eduard Bachmakov2015-01-10
| | | | | | - libmad and faad have been dropped for libav - CC is exported since pianobar forces CC=c99 else - add myself to maintainers
* licenses: comment about two versions of MITVladimír Čunát2014-08-30
| | | | | I decided to follow spdx.org and not to differentiate those two. Packages would often have the wrong version anyway.
* Fix pianobar license to be accurate (MIT)Philip Horger2014-08-30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was broken, in a well-intentioned way, in 9350c1d. The maintainer believed that the Pandora license was in conflict with nixpkg's rights to build the package, and that it would be safer to avoid picking a fight. However well-intentioned, though, it was still inaccurate and unnecessary to change the metadata for the package nixexpr. I will attempt to support this assertion through several arguments that should hopefully be independent, such that any one of them would be convincing enough in isolation to merit merging this commit. 1. The limits of Pandora's TOS The legal agreement between Pandora and its users applies to the user, not to third parties. It definitely does not have such an outrageous scope that Pandora should be allowed to dictate what we may or may not compile. Furthermore, most TOS and EULA documents are completely (or at least mostly) legally bunk. They are constructed such that using any website or software in a typical manner will result in a violation, and the consequences for violation are then enforced selectively. However, when such issues go to court, the court regularly favors the user. Legal precedent generally follows that such agreements are non-binding scare tactics, rather than enforceable contracts. 2. Most software can be used for evil If I buy a lockpick kit, it may have a fully open-source hardware design, be 3D-print-able, etc. And as long as I don't use it to break into someone else's home, it is perfectly appropriate for me to manufacture as many copies as I want, and contribute improvements upstream. Conversely, if I do misuse the tools, and I am prosecuted, the person who made the designs available online is *not* responsible for how I used them. If we only package things that cannot be used for evil, we'll have to stop shipping the Linux kernel, and that could make things... complicated. But it certainly would discourage the NSA from using NixOS. 3. Intent doesn't matter There was an argument, in channel, that pianobar's intent is entirely or predominantly illegal. This is not true, as I'll explain shortly, but I'd first like to explain why intent does not matter. First of all, intent is subjective. If someone bumps me on the street, I may infer ill intent. But from the other person's perspective, she's just in a rush to get from Point A to Point B. Second, intent is not related to consequences or development methodology. Ill intent may lead to positive consequences, and vice versa, and in all cases the subjectivity argument applies (good for whom? bad for whom?). 4. Pianobar does not have bad intent Just look at the project page: http://6xq.net/projects/pianobar/ The "most important" means of contribution, according to author, is keeping Pandora alive. In fact, monetary donations of any kind will not be accepted. This seems like it's in conflict with one of the most popular features of the software - an ad-free experience. But pianobar actually has a better experience when you have a paid Pandora account - higher-quality streams become available. Pianobar is fully compatible with paid accounts, and if the developer does not pay for his Pandora account, I will eat my hat. Furthermore, a command line client enables more people to use Pandora in more ways than the stock Pandora client allows. The stock client is written in Flash, and is slow, resource-hungry, and useless on a headless server. Pianobar can be used on just about any hardware, and there are several hardware recipes listed on the project page which provide straightforward Pandora-based music appliances, using pianobar's minimal footprint and remote-control-ability. Because it opens up more use cases and improves the experience for paid users, it's actually arguable whether pianobar is "bad for Pandora", when it clearly *could* be the opposite. It is also probably fair to note that pianobar has been around for awhile, and Pandora has never expressed an interest in picking a legal fight with it, or even blocking pianobar from working. 5. Pianobar's source really is MIT-licensed It is disingenuous to say that pianobar is nonfree. It's absolutely free software, you can verify the license content against the MIT license text for yourself. It is developed and distributed as free and open source software. The extent of its 'nonfreedom' is that it interacts with a nonfree service, in ways that the nonfree service may not allow for in their TOS. To block it on these grounds, would be like blocking Libreoffice for its Microsoft Word compatibility, or preventing users from visiting websites that say "this site only for use with IE7". ------------ In summary, we should strive for technical accuracy, rather than allowing a third-party pseudocontract that does not apply to us, to dictate what we may or may not package for our users (who may or may not use it in a way that benefits Pandora).
* pianobar: Change license and clean up codeBenjamin Cahill2013-06-08
| | | | | The license was set to unfree so that Hydra doesn't build it; this is for potential problems arising from the Pandora TOS.
* Add pianobar, a command-line Pandora clientBenjamin Cahill2013-06-07