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).
In case you wonder: PNG support is needed for example to generate
spectograms.
For example:
sox shiny-song.flac -n spectrogram -o even-shinier.png
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With this commit, the following new upstream versions are introduced:
stable: 36.0.1985.125 -> 37.0.2062.94
beta: 37.0.2062.58 -> 37.0.2062.94
dev: 38.0.2107.3 -> 38.0.2125.8
All channels built fine on my machine and were tested against a few
sites.
Stable and beta channel now contain the same release, because version
37 hit the stable channel. For release notes, please have a look at the
announcement:
http://googlechromereleases.blogspot.de/2014/08/stable-channel-update_26.html
Of course we're also dropping all version 36 specific crap, such as the
architecture-specific target suffix for builds, which now is no longer
needed.
The gyp flag use_mojo=0 is no longer needed, as it was a workaround
concerning version 37.0.2054.3 only.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
We no longer need to supply compiler and binutils to the build process,
se we can safely remove them. In addition, we're now passing the new
options linux_use_gold_binary and linux_use_bundled_gold to gyp, for
details, see:
https://codereview.chromium.org/239163003
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
(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.
Several of its buildInputs (given in all-packages.nix) does not exist
anymore (version updates and attribute renaming?).
Mark as broken to unblock nixpkgs channel.
Linux Stopmotion is a program for creating stop-motion animation movies.
http://linuxstopmotion.org/
I had to apply a small patch to make grabbing images from webcam work
(using uvccapture). I find it odd that it didn't work without the patch,
seeing that Arch Linux also have the v0.8.0 version, but with no patch.
Latest Ubuntu (14.04) has v0.7.2, which is unaffected.
"Capture image from USB webcam at a specified interval"
I apply patches from Debian to make it build with V4L2 (instead of v1
API) and fix some warnings/bugs. Source code is also downloaded from
Debian, as uvccapture homepage is unavailable.
Homepage: http://linux-uvc.berlios.de/ (seems to have vanished...)
Pulled patches from Debian and hacked around linking errors.
I'm able to ring my mobile phone now.
However, on exit the process is stuck and needs kill -9.
CC: maintainer @MarcWeber.
The following packages are broken with GHC 7.8.3:
- filesystem-conduit version 1.0.0.2
- ghc-events-analyze version 0.2.0
- haskelldb version 2.2.2
- haskell-mpi version 1.2.1
- haxr-th version 3000.5
- hoauth version 0.3.5
- holy-project version 0.1.1.0
- hoogle version 4.2.32
- hspread version 0.3.3
- instant-generics version 0.4
- ivor version 0.1.14.1
- jmacro-rpc-happstack version 0.3
- lambdacube-engine version 0.2.4
- language-c-inline version 0.6.0.0
- lockfree-queue version 0.2.3
- monad-peel version 0.1.1
- network-transport-tests version 0.1.0.1
- poppler version 0.12.3
- profiteur version 0.1.2.1
- prolog-graph-lib version 0.2.0.1
- semigroupoid-extras version 4.0
- setlocale version 0.0.3
- sized-types version 0.5.0
- snaplet-postgresql-simple version 0.5
- snap-loader-dynamic version 0.10.0.2
- uhc git version 20120502
- uniqueid version 0.1.1
- unix-process-conduit version 0.2.2.3
- vado version 0.0.1
- vcsgui version 0.0.4
- xml-html-conduit-lens version 0.3.2.0
The following packages depend on one of the broken ones above:
- hoodle-builder version 0.3
- hoodle-core version 0.14
- hoodle-extra version 0.1
- hoodle-parser version 0.3
- hoodle-render version 0.4
- hoodle-types version 0.3
- hoodle version 0.3
- kansas-lava version 0.2.4
- liblastfm version 0.4.0.0
- prolog-graph version 0.1.0.2
- vacuum-cairo version 0.5
- wcwidth version 0.0.2
teamspeak_client: Use the quazip library provided by teamspeak
This commit should be squashed before being commited to nixpkgs!
Signed-off-by: Domen Kožar <domen@dev.si>
The patch to allow using license shortnames as attributes
was not included (yet).
Conflicts (auto-solved):
pkgs/development/libraries/libtiff/default.nix
Also update its dependencies.
Update libcdr to 0.1.0
Update libmwaw to 0.3.2 from 0.3.1
Update libvisio to 0.1.0
Update libwpd to 0.10.0
Update libwpg to 0.3.0
These updates are require by LO update and also require each other.
Note that many of these libraries now require librevenge.
In LibreOffice expression per se:
- Note that liborcus is built separately because it wants Boost to be
specified in a way that main LO build doesn't ensure.
- libixion from 0.7.0 tarball has libixion-0.8 package version.
- libgltf is in src/libgltf but listed in download.lst without any
comments.
- Make variable with the name libreoffice-translations-${version}.tar.xz
and the same value is inserted; the same for -help-. Fetching gives
a strange error without that. Apparently everyone just builds git
checkouts.
- There are some conditionals in download.lst that require manual
handling. I am not sure there is a simple way to process them in
generate-libreoffice-srcs.sh.
beta: 37.0.2062.44 -> 37.0.2062.58 (builds fine, tested)
dev: 38.0.2101.0 -> 38.0.2107.3 (builds fine, tested)
Drop patch for fixing angle build for the dev version, because it was
applied upstream already.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
I had to update all the pyside programs, or freecad failed to build. I picked
the versions advertised in http://qt-project.org/wiki/PySideDownloads . The
rest I took for github latest releases.
Unfortunately, running them in parallel sometimes lead to tests not even
starting up. Probably lock contention is the issue here, but haven't
investigated further so I'm deactivating parallel testing.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The reason I went through this whole journey of gathering dependencies
and debugging just in order to get i3 tests working was because I wanted
to supply test cases to a small patch I wrote for the upstream project.
This adds/updates quite a few Perl packages and a X dummy helper, which
are all needed in order to successfully run the test suite.
The exit code of the i3 test runner is always 0, regardless of whether
tests were failing or not, so let's quickly grep for a "not ok" in the
test logfile and if it occurs, the whole build is failing now.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Finally, after going through the journey of debugging and gathering
dependencies, we now have tests for i3, hooray!
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
- To fix build problems, I refactored the build process
according to Mozilla recommendations.
- 31.0 should become the next ESR branch (31 released today).
CC @nbp @edolstra
(cherry picked from commit adc2edd5cf)
This version of module has disabled socketActivation, because until
nixos upgrade systemd to at least 214, systemd does not support
SocketGroup. So socket is created with "root" group when
socketActivation enabled. Should be fixed as soon as systemd upgraded.
Includes changes from #3015 and supersedes #3028
Unfortunately they've changed their build system to be makefile-only and
they don't seem to include test cases in the CLI anymore, so we needed
to adapt accordingly. Also added freealut and openal to the buildInputs,
in order to allow audio support.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
With this commit, the following new upstream versions are introduced:
stable: 35.0.1916.153 -> 36.0.1985.125
beta: 36.0.1985.84 -> 37.0.2062.44
dev: 37.0.2054.3 -> 38.0.2101.0
All builds were successfully tested on my machine, however in order to
update the beta and dev channels, a few additional modifications were
necessary:
* Don't update address_input_strings.grdp anymore because this has been
done/fixed upstream and was relevant in version 37.0.2054.3 _only_.
* No need to fix references to /usr/bin/gcc in version 38 anymore.
* Constrain patch for Angle (introduced in 4cbedd7) to version 37 only,
because it already has been applied upstream in version 38.
* Drop user namespaces patch for version 31 up until version 35,
because version 36 is already in stable.
* Don't try to build bundled Clang and/or even build using Clang.
* Remove obsolete patchPhase commands that are specific to version 35
and older.
While testing the dev version 38 I came accross a font rendering issue
which needs to be addressed ASAP (perhaps related to #3187), however the
browser works otherwise.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
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
- To fix build problems, I refactored the build process
according to Mozilla recommendations.
- 31.0 should become the next ESR branch (31 released today).
CC @nbp @edolstra
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.
Hydra: ?compare=1138350
Conflicts:
nixos/modules/services/x11/desktop-managers/default.nix
Two imports were added independently on the same line.
I split it as well, as it was very long now.
I don't see a reason for having wrapVim function and vimWrapper and
vimHugeXWrapper packages. If you need a system vimrc, whats wrong with
``environment.etc."vimrc".text`` ?
Also strictly speaking ``vimHugeXWrapper`` didn't wrap, X-version
properly. I.e. running ``gvim`` have console vim version.
This includes another source-only derivation for the web interface (and
patches the path into the twister binary), so there shouldn't be a need
to move it into ~/.twister/html separately.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
version number so that it's possible to refer to some "default version of the
package" without knowing what version number that actually is.
The same applies to idea_ultimate_1313.
Verified working with Firefox, however it still doesn't work with
Chromium because of the NPAPI vs PPAPI thing.
Chrome's Pepper Plugin API doesn't seem to look for
plugins in the MOZ_PLUGIN_PATH, anyway I left them there for others to
find the solution :-)