3
0
Fork 0
forked from mirrors/nixpkgs
Commit graph

24 commits

Author SHA1 Message Date
R. Ryantm 4b5380f30d pianobar: 2020.11.28 -> 2022.04.01 2022-04-05 17:20:50 +00:00
Thomas Gerbet 885caf29af pianobar: use ffmpeg4
See migrate away from ffmpeg_3 #120705.
2021-05-02 12:04:54 +02:00
Jonathan Ringer 9bb3fccb5b treewide: pkgs.pkgconfig -> pkgs.pkg-config, move pkgconfig to alias.nix
continuation of #109595

pkgconfig was aliased in 2018, however, it remained in
all-packages.nix due to its wide usage. This cleans
up the remaining references to pkgs.pkgsconfig and
moves the entry to aliases.nix.

python3Packages.pkgconfig remained unchanged because
it's the canonical name of the upstream package
on pypi.
2021-01-19 01:16:25 -08:00
Anderson Torres fe0b3800c1
Merge pull request #105770 from r-ryantm/auto-update/pianobar
pianobar: 2020.04.05 -> 2020.11.28
2021-01-16 16:23:09 -03:00
Profpatsch 4a7f99d55d treewide: with stdenv.lib; in meta -> with lib;
Part of: https://github.com/NixOS/nixpkgs/issues/108938

meta = with stdenv.lib;

is a widely used pattern. We want to slowly remove
the `stdenv.lib` indirection and encourage people
to use `lib` directly. Thus let’s start with the meta
field.

This used a rewriting script to mostly automatically
replace all occurances of this pattern, and add the
`lib` argument to the package header if it doesn’t
exist yet.

The script in its current form is available at
https://cs.tvl.fyi/depot@2f807d7f141068d2d60676a89213eaa5353ca6e0/-/blob/users/Profpatsch/nixpkgs-rewriter/default.nix
2021-01-11 10:38:22 +01:00
R. RyanTM 590d2c63e7 pianobar: 2020.04.05 -> 2020.11.28 2020-12-03 06:57:36 +00:00
Doron Behar 01d4e2fe33 treewide: use ffmpeg_3 explicitly if not wanted otherwise
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.
2020-06-12 11:55:31 -07:00
R. RyanTM 64e666f772 pianobar: 2019.02.14 -> 2020.04.05 2020-04-12 17:33:45 -07:00
Robin Gloster 43e91d6f07
pianobar: *Flags are lists 2019-12-30 11:44:38 +01:00
Mario Rodas 9499f4f5c1
pianobar: enable on darwin 2019-09-17 20:38:51 -05:00
R. RyanTM c39795ed46 pianobar: 2018.06.22 -> 2019.02.14 (#58750)
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
2019-04-07 23:13:01 +02:00
Ricardo M. Correia 1a1257898e pianobar: 2016.06.02 -> 2018.06.22 (#45913) 2018-09-01 21:35:10 +02:00
Anton-Latukha 8f101cce83 rm maintainer eduarrrd from packages, no activity > year 2018-07-22 21:41:48 +03:00
volth 52f53c69ce pkgs/*: remove unreferenced function arguments 2018-07-21 02:48:04 +00:00
John Ericson ed14223f8c treewide: Manual fix more pkg-config build-inputs 2017-09-21 15:49:54 -04:00
Silvan Mosberger f5fa5fa4d6 pkgs: refactor needless quoting of homepage meta attribute (#27809)
* 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
2017-08-01 22:03:30 +02:00
Kranium Gikos Mendoza b15b32082d pianobar: 2015.11.22 -> 2016.06.02 2016-06-22 16:28:43 +08:00
Eduard Bachmakov f119de4b35 pianobar: 2014.09.28 -> 2015.11.22 2016-01-14 22:25:39 -05:00
Pascal Wittmann bb9e9cc3f8 Turned some meta.maintainers into lists 2015-05-14 19:09:43 +02:00
Eduard Bachmakov 0d7c055c54 pianobar: update to pianobar-2014.09.28
- libmad and faad have been dropped for libav
- CC is exported since pianobar forces CC=c99 else
- add myself to maintainers
2015-01-10 16:44:50 -05:00
Vladimír Čunát 3f0ebe7e75 licenses: comment about two versions of MIT
I decided to follow spdx.org and not to differentiate those two.
Packages would often have the wrong version anyway.
2014-08-30 07:28:26 +02:00
Philip Horger f7aa6e1140 Fix pianobar license to be accurate (MIT)
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).
2014-08-30 07:24:32 +02:00
Benjamin Cahill 9350c1d5ce pianobar: Change license and clean up code
The license was set to unfree so that Hydra doesn't build it; this is
for potential problems arising from the Pandora TOS.
2013-06-08 14:13:36 -05:00
Benjamin Cahill 00e720471b Add pianobar, a command-line Pandora client 2013-06-07 20:52:34 -05:00