Re: [Nix-dev] Zero Hydra Failures (ZHF) project
Great success! \o/ Thank you for doing that! Domen Kožar do...@dev.si writes: During the NixOS Sprint in Ljubljana I worked on ZHF project, mostly tackling python packages. I'm still fighting with pypy and sqlite3, but in general we should be down to around 300 failing builds for NixOS. What's left are mostly kernelPackages and some haskell/ocaml stuff. http://hydra.nixos.org/eval/1149989#tabs-still-fail On Fri, Aug 29, 2014 at 5:38 PM, Luca Bruno lethalma...@gmail.com wrote: Progress: we started having 10248 failures, then at 12 Aug 8028 failures, and now 6126 failures. I'd like to thank everybody. Let's keep up the good work! Many of the python packages got banned from being built with different versions of python (e.g. python2 packages that don't build on python3). Same goes for haskell packages. Thanks for the work! However a big chunk are failing on darwin. The reason is common to many darwin packages (also python packages): pbuilding ppm2tiff tiffgt.c:38:20: fatal error: GL/gl.h: No such file or directory # include GL/gl.h ^ compilation terminated. In the libtiff package specifically, which causes the failure of a bunch of dependent packages. I hope darwin users can spend some time fixing this inconvenient issue. Another big chunk of failing packages are the pypy ones, due to failing pypy urllib. Fixing these two issues alone should drop the red numbers a lot. ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev -- Florian Friesdorf f...@chaoflow.net GPG FPR: 7A13 5EEE 1421 9FC2 108D BAAF 38F8 99A3 0C45 F083 Jabber/XMPP: f...@chaoflow.net IRC: chaoflow on freenode,ircnet,blafasel,OFTC pgpflJHPLbnwQ.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] processing: new package
processing: new package
---
diff --git a/pkgs/applications/editors/processing/default.nix
b/pkgs/applications/editors/processing/default.nix
new file mode 100644
index 000..021f863
--- /dev/null
+++ b/pkgs/applications/editors/processing/default.nix
@@ -0,0 +1,55 @@
+{ stdenv, fetchurl, lib, makeWrapper
+, ant, rsync, jdk, jre
+, which
+}:
+
+stdenv.mkDerivation rec {
+ name = let
+a_tag = 0227;
+the_version = 2.2.1;
+ in processing-${a_tag}-${the_version};
+
+ src = fetchurl {
+url = https://github.com/processing/processing/archive/${name}.tar.gz;;
+sha256 =
b38352f5a7bd22db3287274356fa87c614132960574f2ecb55f83e02812f18e5;
+ };
+
+ patches = [ ./use-local-jre.patch ];
+
+ buildInputs = [
+ant
+makeWrapper
+rsync
+jdk jre
+ ];
+
+ buildPhase = ''
+cd build
+ant build
+ '';
+
+ installPhase = let
+pkg_path = $out/${name};
+bin_path = $out/bin;
+runtime_paths = lib.makeSearchPath bin [
+ jre
+ which
+];
+ in ''
+mkdir -pv ${pkg_path}
+cp -a linux/work/* ${pkg_path}/
+# XXX: not such a good idea?
+ln -s ${jdk} ${pkg_path}/java
+mkdir -pv ${bin_path}
+makeWrapper ${pkg_path}/processing ${bin_path}/processing \
+ --prefix PATH : ${runtime_paths}
+makeWrapper ${pkg_path}/processing-java ${bin_path}/processing-java \
+ --prefix PATH : ${runtime_paths}
+ '';
+
+ meta = {
+description = Development environment for Processing programming
language.;
+homepage = http://processing.org;
+license = LGPL/GPLv2;
+ };
+}
diff --git a/pkgs/applications/editors/processing/use-local-jre.patch
b/pkgs/applications/editors/processing/use-local-jre.patch
new file mode 100644
index 000..33864a0
--- /dev/null
+++ b/pkgs/applications/editors/processing/use-local-jre.patch
@@ -0,0 +1,67 @@
+diff -Naur a/build/build.xml b/build/build.xml
+--- a/build/build.xml 2014-05-20 10:04:07.0 +0900
b/build/build.xml 2014-08-30 11:23:09.632834129 +0900
+@@ -640,10 +640,11 @@
+ value=jre-tools-6u37-linux${sun.arch.data.model}.tgz /
+ --
+
++!--
+ get src=http://processing.googlecode.com/files/${jre.file};
+dest=linux/jre.tgz
+usetimestamp=true /
+-
++--
+ !--
+ Cannot use ant version of tar because it doesn't preserve properties.
+ untar compression=gzip
+@@ -655,39 +656,48 @@
+ !--
+ http://www.gnu.org/software/tar/manual/html_section/transform.html
+ --
++!--
+ exec executable=tar dir=linux
++--
+ !-- Change directory --
+ !--
+ arg value=-C /
+ arg value=linux/work /
+ arg value=-xzpf /
+ --
++!--
+ arg value=xfz /
+ arg value=jre.tgz/
+ /exec
++--
+
+ !--
+ We only want to move when the folder didn't exist before
+ move file=linux/jre1.7.0_40 tofile=linux/work/java /
+ --
++!--
+ exec executable=rsync dir=linux
+ arg value=-a /
+- arg value=--delete /
++ arg value=- -delete /
+ arg value=jre1.7.0_40/ /
+ arg value=work/java /
+ /exec
+ delete dir=linux/jre1.7.0_40 /
++--
+
+ !-- Remove unused JRE bloat. --
++!--
+ delete
+ fileset refid=javafx-basics /
+ fileset refid=javafx-linux-${sun.arch.data.model} /
+ fileset refid=jre-optional-linux /
+ /delete
+-
++--
++!--
+ copy todir=linux/work/java/lib/fonts
+ fileset dir=shared/lib/fonts includes=* /
+ /copy
++--
+
+ /target
+
diff --git a/pkgs/top-level/all-packages.nix b/pkgs/top-level/all-packages.nix
index 6f02f26..aaa50ce 100644
--- a/pkgs/top-level/all-packages.nix
+++ b/pkgs/top-level/all-packages.nix
@@ -1929,6 +1929,8 @@ let
pastebinit = callPackage ../tools/misc/pastebinit { };
+ processing = callPackage ../applications/editors/processing { };
+
psmisc = callPackage ../os-specific/linux/psmisc { };
pstoedit = callPackage ../tools/graphics/pstoedit { };
___
nix-dev mailing list
nix-dev@lists.science.uu.nl
http://lists.science.uu.nl/mailman/listinfo/nix-dev
[Nix-dev] Package archeology in nixpkgs
Hi all, I've had a sudden urge to do some Haskell archeology and that led me to a question about how we feel philosophically about keeping abandoned projects and old versions of live projects in nixpkgs. I think it could be valuable to preserve important pieces of Haskell history (and perhaps other projects) and it seems like nix is uniquely positioned to be able to do that well. I don't propose keeping all versions of all the compilers around, but I'd like to pick out key points in history and preserve them. In particular, I was thinking of attempting to get the following working: - HBC: perhaps the original Haskell compiler. I'd probably aim for a version that implements Haskell 1.4 and one before that standard was even proposed. Polymorphic map and (++) in Prelude! - NHC: can build it with HBC - GHC: the latest version that supports linear implicit parameters, because they're gone now and I think people should be able to tinker with them The nice thing about doing this sort of thing with compilers is that they tend to not have many dependencies, but I expect I might also need to package up an old version of yacc for HBC. If it starts getting too messy I might abandon the project, but I think it could work fairly nicely. This would also pave the way to exploring other interesting abandoned projects like fudgets and such. How do people feel about this? Is it something I should maintain independently of nixpkgs or does it belong in the main repo? Thanks, Dan ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
Re: [Nix-dev] Package archeology in nixpkgs
- NHC: can build it with HBC According to [1], it can be bootstrapped via C. If I remember correctly, I successfully built it this way in the past (outside of NixOS). How do people feel about this? I think it’s a great idea. I always wanted to try HBI, which “supports the full language at the command line.” [2] But I have no idea where to get the source. [1] http://www.haskell.org/nhc98/download.html [2] http://stackoverflow.com/questions/4084790/compilers-for-haskell/5918876 pgp_aVy7aiE0O.pgp Description: PGP signature ___ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev
