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.
Currently, we have a 'jack' package with attrname 'jack1d' and a
'jackdbus' package with attrname 'jackaudio'. Make it consistent 'jack1'
and 'jack2' in both package name and attrname.
This aligns the naming with what can be found on the JACK homepage.
Q: what's the difference between jack1 and jack2?
A: http://trac.jackaudio.org/wiki/Q_differenc_jack1_jack2
The one-liner gcc buildPhase doesn't work anymore, so I'm using upstream
Makefile instead. The Makefile needs a tiny patch to work (not nixpkgs
specific).
Also fixup path to 'sox' and espeak-data/ (runtime deps) by providing
full paths.
TODO:
Uhm, seems like espeakedit still wants espeak-data/ in $HOME, even
thought I've told it to use $espeak/share/espeak-data. Have to contact
upstream to get this fixed.
Workaround:
cp -r $(nix-build -A espeak)/share/espeak-data ~
chmod +w ~/espeak-data
Using setup.py results in the following error message:
Missing file: share/applications/gpodder.desktop
If you want to install, use "make install" instead of using
setup.py directly. See the README file for more information.
Suite of command line utilities for transcoding video and audio codecs,
and for converting beween different container formats.
http://www.transcoding.org/
$ nix-env -f . -qa '*' --meta --xml --drv-path --show-trace
error: while querying the derivation named `clementine-1.2.1':
while evaluating `optional' at .../lib/lists.nix:113:20, called from .../pkgs/applications/audio/clementine/default.nix:50:22:
undefined variable `not' at .../pkgs/applications/audio/clementine/default.nix:50:32
Clementine has an optional dependency on libspotify, which is unfree.
Enabling libspotify unconditionally prevented Hydra from distributing
Clementine. Now, we optionally enable it based on
config.clementine.spotify.
Changes since 0.7.5:
* added libav 10 and ffmpeg 2.2 support;
* fixed url parsing;
* fixed freezing on playback resume;
* fixed random freezing in the mplayer plugin;
* fixed reset selection of tracks when calling context menu;
* fixed multimedia keys support under win32.
The one in gnome2 was failing to build,
but all there is likely in a desolate state anyway.
In gmpc it also seemed without any reason to have a duplicate.
There's a zlib version included with milkytracker,
but there's no makefiles for it. I've only included
the header here, but it fails at link-time with
several 'undefined reference' errors, which simply
means it can't find the definitions, e.g. compiled
zlib.
There's bug reports on other package systems although
unfortunately still unresolved.
https://bugs.archlinux.org/task/31324http://lists.freebsd.org/pipermail/freebsd-ports/2013-March/082180.html
Compiles fine on linux i686 and amd64. Adding myself as maintainer, even
though I'm not using the package by myself, but a friend is using it for
DJing from a NixOS live system I'm maintaining.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Spotify doesn't start:
$ ./result/bin/spotify
/nix/store/yx05s6irqil8a24ilyvjvhnjljmm8f15-spotify-0.9.4.183/bin/.spotify-wrapped: error while loading shared libraries: libcef.so: cannot open shared object file: No such file or directory
That is fixed with adding $out/spotify-client/Data to RPATH.
Then Spotify errors out trying to open libudev.so.0. We don't have that
in nixpkgs, so I'm making a symlink to libudev.so.1 instead.
Tested on NixOS x86_64-linux.
* Remove package name
* Start with upper case letter
* Remove trailing period
Also reword some descriptions and move some long descriptions to
longDescription.
I'm not touching generated packages.
There are many more packages to fix, this is just a start.
Rules:
* Don't repeat the package name (not always that easy...)
* Start with capital letter
* Don't end with full stop
* Don't start with "The ..." or "A ..."
I've also added descriptions to some packages and rewritten others.
That way we have the fingerprinter preselected in the configuration file
and the user doesn't need to search with an "open file" dialog inside
the Nix store.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Changes since 1.1:
- Picard now requires at least Python 2.6
- Removed support for AmpliFIND/PUIDs
- Add support for the Ogg Opus file format
- It's now possible to download cover images without any plugin. Cover
Art Archive images can be downloaded by image type
- Improved directory scanning performance
- Prefer already-loaded releases of the same RG when matching files
- Allow dropping new files onto specific targets
- Add basic collections management support (PICARD-84)
- Allow adding custom tags in the tag editing dialog (PICARD-349)
- Fix replacing of Windows-incompatible characters (PICARD-393)
- Save both primary and secondary release types (PICARD-240)
- Handle errors from the AcoustID service better (PICARD-391)
- Accept HTTPS URLs on drag-and-drop (PICARD-378)
Full release announcement can be found here:
http://blog.musicbrainz.org/2013/03/31/picard-1-2-released/
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Easytag has moved to gnome.org and thus this commit also updates and cleans up a
few meta attributes. More information about the move can be found in the
announcement:
https://mail.gnome.org/archives/easytag-list/2012-November/msg00006.html
In order to get it to compile, we need to do a bit of patching, for example the
configure script tries to find libid3tag through pkg-config, but unfortunately
libid3tag doesn't have a *.pc script, so we're patching it out of the configure
script and use NIX_LDFLAGS to inject the library during linking (note the "-lz"
- it's a propagated dependency of libid3tag).
Also added for MP4 support: taglib.
Thanks to @devhell for the notification of the new upstream release.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- Using system-wide libs where we have them (except for portaudio, which
I couldn't make work).
- Add the soxr library (now the preferred way of audio resampling).
Without the --disable-nptl-bug-check configure option LinuxSampler
refuses to build. It seems to be a long standing bug. Despite this, I
have used LinuxSampler for over a week now and it seems OK.
A tarball is only available to subscribers or people who pay
to download it on the site. This project is GPL licensed but
users are strongly encouraged to support it financially
This patches the Hydrogen scons build script to work a failure to
parse the JACK version correctly. If I understand correctly upstream
Hydrogen now uses cmake instead of Scons, so this shouldn't be a
problem with the next Hydrogen release.
As we are still mainly on gtk2, so I'm disabling gtk3 support for now. Though we
might want to add an option enableGTK3 someday.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- Added support for MusicBrainz queries to abcde package
- Added new dependencies to abcde: mkcue, eject, perl, MusicBrainz, MusicBrainzDiscID
- libdiscid version in pkg-config was incorrect; patched libdiscid to fix
- Added WebServices::MusicBrainz Perl module
- Added MusicBrainz::DiscID Perl module
- Commented out XSLoader Perl module since it was broken, no packages depend on it,
and it has been incorporated into the Perl core
This merges branches 'libarchive.121020', 'gphoto2.121020' and 'ncmpcpp.121020'
of git://github.com/jcumming/nixpkgs.
Octopus merge of @jcumming's minor updates, apart flrom updating the version, a
few other changes were made to these packages as well:
* libarchive: Now depends on xz.
* libgphoto: License changed to LGPL 2.1 plus.
And he did an overhaul of some of the meta blocks as well.
Changes during this merge:
* Inline and reword stray comment into meta tag in
1db34880d7 (libgphoto).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
![](/avatar/2f93d08a773b27d6548598c5f45aa3a9?size=56 "Jason \\"Don\\" O'Conal"){kind=small}
