The repo has been split into smaller repos and it will require some more
work to get it building again and to figure out which ports and plugins
to include.
Even though we build from git tag 3.5.403, `ardour --version` reports
3.5-380-g2f6065b. Fix it.
(Another way to fix this is to clone the whole git repo, preserve the
.git/ directory and add git as buildInput so that Ardour can figure out
all this version info stuff by itself.)
Attrnames and package names should be as close as possible to avoid confusion.
I took care not to confuse the two mpc things during the mass-replace,
so hopefully I suceeded (tarball still builds).
Makes beets actually usable (and configurable) on Nix(OS), if you want
to use more plugins rather than just plain lookup of tracks based on
(fuzzy) string matching.
This also changes the derivation name from "python2.7-beets" to just
"beets".
* Commit summary:
beets: Check dependencies on activated plugins.
beets: Check plugin definitions against package.
beets: Use audiotools backend for replaygain.
beets: Allow to configure plugin dependencies.
beets: Switch to using fetchFromGitHub.
python: Add new package audiotools.
python: Add new package discogs_client.
python: Add pyacoustid and dependencies.
python/mutagen: Update to upstream version 1.27.
mp3gain: Fix output path bin directory.
beets: Add myself to maintainers.
beets: Update to new upstream version 1.3.9.
beets: Move into its own package directory.
Name has been changed in c9282c65f4.
Users would probably expect "nix-env -i picard" to work, and as picard
isn't a library it doesn't make sense to set a prefix.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Using propagatedBuildInputs only works for environment.systemPackages
but not for using nix-env, because on NixOS we already have a default
QT_PLUGIN_PATH set there.
The main reason why I'm using the VLC backend and not providing options
for other Phonon backends is because it's recommended upstream and also
will be directly used (via libvlc) in the upcoming 0.9 release.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Fixes a few annoying bugs (in my case it's the painting issue that's
most annoying):
* Show error message if saving tags failed.
* Fixed painting issue on search page.
* (OS X & Windows) Fixed crash during collection scan.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Adds the Tomahawk music player (https://www.tomahawk-player.org/) in
version 0.8.1 and all its required and optional dependencies.
* tomahawk:
tomahawk: Add new package, version 0.8.1.
libjreen: Add new package, version 1.2.0.
websocketpp: Add new package, version 0.4.0.
lucenepp: Add new package, version 3.0.6.
qtkeychain: Add new package, version 0.4.0.
libechonest: Add new package, version 2.3.0.
quazip: Use qt instead of qt5 for refering to Qt.
Although I've not tested the Tomahawk build on Mac OS X, it *should*
work on it, so I'm using platforms.all here.
Telepathy and KDE support are disabled by default in order to not get in
the way of users who want to use a more minimalistic window-manager-only
setup. But I'm not sure whether it matters in reality, we'll see once
more people are using Tomahawk.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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).
(My OCD kicked in today...)
Remove repeated package names, capitalize first word, remove trailing
periods and move overlong descriptions to longDescription.
I also simplified some descriptions as well, when they were particularly
long or technical, often based on Arch Linux' package descriptions.
I've tried to stay away from generated expressions (and I think I
succeeded).
Some specifics worth mentioning:
* cron, has "Vixie Cron" in its description. The "Vixie" part is not
mentioned anywhere else. I kept it in a parenthesis at the end of the
description.
* ctags description started with "Exuberant Ctags ...", and the
"exuberant" part is not mentioned elsewhere. Kept it in a parenthesis
at the end of description.
* nix has the description "The Nix Deployment System". Since that
doesn't really say much what it is/does (especially after removing
the package name!), I changed that to "Powerful package manager that
makes package management reliable and reproducible" (borrowed from
nixos.org).
* Tons of "GNU Foo, Foo is a [the important bits]" descriptions
is changed to just [the important bits]. If the package name doesn't
contain GNU I don't think it's needed to say it in the description
either.
