Although this is a release canidate version of kernel 3.12, there are
reasons for merging this anyway, as discussed in #1010 and #1006.
Thanks to @offlinehacker for this and the initial pull request.
Ditaa is a small command-line utility written in Java, that can convert
diagrams drawn using ascii art ('drawings' that contain characters that
resemble lines like | / - ), into proper bitmap graphics.
Homepage: http://ditaa.sourceforge.net/
That workarounds the coldplug problem
$ sudo ./libexec/upowerd -v
TI:18:38:27 Starting upowerd version 0.9.19
...
TI:18:38:27 registering subsystem : usb
TI:18:38:27 failed to coldplug /sys/devices/pci0000:00/0000:00:1c.4/0000:03:00.0/usb1
<upowerd EXITS>
- Add config to defaults.yaml, to allow topologies to include their own storm.yaml.
- Symlink extra jars in lib/ since it's nearly impossible to add a classpath to Storm's config.
- Include native jzmq library in java.library.path
- Use package default args.
- The bin/storm script makes too many assumptions about file locations and java classpath that I couldn't figure out a better way.
Fix jzmq build on NixOS: java source was treated as ASCII.
unoconv is a tool that converts between any document format supported by
LibreOffice/OpenOffice.
Example of how to convert an .odt file to .pdf:
unoconv -f pdf some-file.odt
Homepage: http://dag.wieers.com/home-made/unoconv/
Implementation notes:
unoconv must use the same python version as libreoffice (unless it will
not be able to load the pyuno module from libreoffice). And because we
recently switched to libreoffice 4.x, which uses python3, I had to
include unoconv-python3.patch. The patch comes from upstream unoconv.git
repo, so it will be included in the next release.
BaseX is a very fast and light-weight, yet powerful XML database and
XPath/XQuery processor, including support for the latest W3C Full Text
and Update Recommendations. It supports large XML instances and offers a
highly interactive front-end (basexgui). Apart from two local standalone
modes, BaseX offers a client/server architecture.
Homepage: http://basex.org/
Implementation notes:
- I'm using the pre-built java package (because it's simple)
- I copied the basex.svg icon file from the Ubuntu package because I
couldn't find it anywhere else. It's 9.3 KiB.
Give dstat access to the "curses" module in the Python standard library
so that it can color its output. This is similar to how other distros
package it (e.g. Fedora, Ubuntu).
Thanks to @phreedom for reporting the broken URL used fetchgit, which
was because I deleted my fork repository. Fortunately, in the meantime
other forks got to a more "working" state and being more actively
maintained than my fork. So that's why I switched using @nemerle's fork
now, as it is the the most usable one out there, at least in our case.
One stupid thing I've done in the first place was to use "1.0pre" as the
version and the fork uses "alpha 0.3.2", so it essentially is some kind
of a "downgrade" if you just look at the version.
Fortunately, peer-unreviewed research based on guesswork has shown that
I'm the only one using Boomerang on NixOS, so this shouldn't have a big
impact on the other non-existent users.
Also, this drops dependencies on boehmgc and cppunit, because building
with either one or both will fail at the moment.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Also leaving 0_8 branch, as it's compatible with older ffmpeg versions.
I'm planning that all expressions will be able to switch easily
between ffmpeg and libav (whatever default we choose, but I prefer libav).
Edited (twice) according to notes on the reverted b003138.
This commit also fixes an issue where pkgconfig was only added as a
dependency when gtk support was enabled. This made ./configure unable
to find other libraries (libtiff, libxml2, gnutls, and others).
The jing expression now creates its own "jing" wrapper script, so there
is no need for jing_tools anymore.
jing hasn't been updated in years, so I assume (or hope) that not many
(if any) have jing_tools in their configuration.nix. If you do, just
change it to jing and it should behave the same.
Duply is a shell front end for the duplicity backup tool
http://duplicity.nongnu.org/. It greatly simplifies it's usage by
implementing backup job profiles, batch commands and more. Who says
secure backups on non-trusted spaces are no child's play?
Homepage: http://duply.net/
it helps, but is incomplete.
more fixes are coming, but including these would change too much
generic btrfs code, which might cause trouble for others.
so the best advice is not to use btrfs send yet and wait for 3.11 or 3.12
Packaged this for @devhell sometime ago and adding it here so maybe it's
useful for other people using Nix(OS).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is the commandline tool for interacting with the chromaprint
library and it's needed for Picard version 1.2 (as it no longer has
support for AmpliFIND/PUIDs).
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is the core component of the AcoustID project and is the library
for extracting/querying of audio fingerprints.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Also leaving 0_8 branch, as it's compatible with older ffmpeg versions.
I'm planning that all expressions will be able to switch easily
between ffmpeg and libav (whatever default we choose, but I prefer libav).
Add linux kernel modules needed to do kernel tracing with LTTng.
To make them available to lttng in NixOS, add this to configuration.nix:
boot.extraModulePackages = [ pkgs.linuxPackages.lttngModules ];
Babeltrace is a command-line tool and library to read and convert LTTng
tracefiles. Give it a (binary) trace file/dir path and it will print a
human readable event log to standard out.
This is the Linux Trace Toolkit. Included in this package:
Command-line client:
lttng
Tracing daemons:
lttng-sessiond (automatically started by lttng)
lttng-relayd (remote trace collection daemon)
Userspace tracing can be done by using liblttng-ust. To do kernel
tracing we also need the LTTng kernel modules.
I've added a patch that changes "/sbin/modprobe" to just "modprobe".
It has been submitted for inclusion in mainline, so it will probably
make it into 3.11 (or 3.12 as 3.11 is fairly close to release).
It is very local, only affecting people who use the "send" feature.
Without it, send is unstable/unsafe to use incrementally.
It can probably be applied to 3.9 and 3.8 as well, but as I only
tested it against 3.10, so I didn't bother.
It turns out that the .deb only contains the changelog and some other docs.
Revert back to using the i686 version, but keep the double url for the future.
The script installed with this expression only copies a boostrapper and another
script to the user's home folder. Those also need to be patched to get on with
the installation.
Conflicts (a little tricky, I did some cleanup of interacting changes):
pkgs/development/compilers/llvm/default.nix
pkgs/development/libraries/libpng/default.nix
pkgs/tools/package-management/nixops/default.nix
pkgs/top-level/all-packages.nix
Having N different copies of the NixOS kernel configuration is bad
because these copies tend to diverge. For instance, our 3.10 config
lacked some modules that were enabled in older configs, probably
because the 3.10 config had been copied off an earlier version of some
older kernel config.
So now there is a single kernel config in common-config.nix. It has a
few conditionals to deal with new/removed kernel options, but
otherwise it's pretty straightforward.
Also, a lot of cut&paste boilerplate between the kernel Nix
expressions is gone (such as preConfigure).
It doesn't make sense to build tools/applications with three different
python interpreter versions, so move them out of python modules list.
Also reverts 53ffc6e0ef.
We cannot import the packages from all of these three packages sets into
the global namespace, because they are indistinguishable. For example:
$ nix-env -qaP \* | grep pylint
pypyPackages.pylint pylint-0.26.0
python33Packages.pylint pylint-0.26.0
python27Packages.pylint pylint-0.26.0
When someone tries to install pylint by running "nix-env -i pylint",
then it's impossible to tell which one of these three versions was
chosen.
I can think of two ways to remedy this problem with recurseIntoAttrs:
1) Bake the name of the Python interpreter into every package's name,
i.e. offer "python27-pylint", "python33-pylint", and so on.
2) Ensure that all non-default package sets mark all their packages
'lowPrio' to unsure that the choice during installation is
deterministic.