pitz is a distributed bug tracker, inspired by ditz. Homepage:
http://pitz.tplus1.com/
pitz has a command line interface, pitz-<command>, and a webapp,
pitz-webapp.
TODO: pitz has a pitz-shell utility that depends on ipython, but when I
enabled it it raised an exception. I think it depends on an old IPython
version:
from IPython.Shell import IPShellEmbed
ImportError: No module named Shell
A broken pitz-shell doesn't affect the rest of the command line
interface nor the webapp, so it is not critical to have it working.
There are not many distributed bug trackers out there, so I hope that
adding pitz to nixpkgs may inspire people to support pitz (or similar
software).
Theoretically this could be automatically detected by finding all
packages named 'linux' and choosing the latest, but that's overkill.
Just update it when a new kernel is added.
Signed-off-by: Shea Levy <shea@shealevy.com>
http://bugs.python.org/issue15833
When Python 3.3.0 attempts to compile python bytecode in the system
directories it raises and exception and stops. Since Python 3.3 is
only required by the latest Blender, I hope it's OK to use the RC
until the final release.
FFMPEG support allows a greater variety of export and import options.
SNDFILE support allows WAV and other sound file formats to be used.
JACK support allows blender to be used with XJadeo, Ardour or any other JACK away audio editor.
Add these new attributes (all default to true):
notebookSupport
qtconsoleSupport
pylabSupport
pylabQtSupport
This adds jinja2, matplotlib, pyqt4 and sip as new dependencies of
ipython.
This commit fixes "ipython --pylab" so that it no more errors out with
"ImportError: No module named matplotlib" (which was my initial goal).
IPython 0.13.1: minor bugfix release for 0.13, on October 20, 2012. This
release includes 41 Pull Requests and closing 21 Issues backported from
0.14-dev, including significant fixes for ipcluster and Python 3.3
compatibility.
Actually only pyGtkGlade was missing in propagatedBuildInputs. In addition,
buildInputs is quite redundant in this case, so let's drop it.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
stable: 25.0.1364.152 -> 26.0.1410.43 (builds fine, tested)
beta: 26.0.1410.28 -> 26.0.1410.43 (builds fine, tested)
dev: 26.0.1410.28 -> 27.0.1448.0 (build fixed and tested)
For version 27, this introduces a new dependency on libXtst and removes the
patch for siginfo_t and the pulseaudio array bounds error.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This patch was introduced before (7e5109a) the stdenv-updates merge and is no
longer needed, as the current C library doesn't use this flag anymore.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The updater was actually getting the -lite version, which our expression won't
build with, except if we switch some bundled dependencies to those in nixpkgs.
Of course the problem with fetching version 27 was me being stupid and using a
case statement in the updater, as if there won't be any version after 26 ;-)
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
Now, our builds shouldn't break anymore once there is a new change in ocamllibs.
I've used revision 256 from ocamllibs, because this was approximately the
revision we had back then when Haxe 2.10 got released.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is required in order to support Haxe 3, but won't hurt (tested with a few
projects) even in Haxe 2.x.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
There are some SVN repositories out there which don't have revision information
tied to externals. By using ignoreExternals, fetchsvn won't fetch these
externals anymore, so the fetch won't fail with a checksum mismatch, should
there be some changes in some of those external repositories.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
That is, there are now distinct jobs like ‘coreutils.x86_64-linux’ and
‘coreutils.x86_64-darwin’, rather than a single job ‘coreutils’ with
multiple builds. This means that testing a job is simpler:
$ nix-build pkgs/top-level/release.nix -A coreutils.x86_64-linux
See https://github.com/NixOS/hydra/issues/60 for the motivation.
An aggregate is a trivial build that depends on other builds. This is
intended to provide a declarative replacement of Hydra's "view"
mechanism.
For instance, you can define an aggregate named "critical" that
depends on a selected set of jobs:
critical = releaseTools.aggregate
{ name = "foo-${tarball.version}";
members =
[ tarball
build.x86_64-linux
...
];
meta.description = "Release-critical builds";
};
The "critical" build will only succeed if all its members
(dependencies) succeed.
