@peti: the recent hydraPlatforms change is a hack right? Because that does not prevent the user from trying to install the package, which will be compiled and will fail.
On Fri, Aug 8, 2014 at 10:45 PM, Luca Bruno <lethalma...@gmail.com> wrote: > That's a good idea for the long-term. However the mechanism for which we > decide that a package is buildable with python2 but not python3 is still a > work in progress. Same goes for other languages like haskell. > So before reaching that automation level it's necessary to step through > this rough problem first. > > > On Fri, Aug 8, 2014 at 10:40 PM, Alexander Kjeldaas <a...@formalprivacy.com> > wrote: > >> >> >> >> >> On Fri, Aug 8, 2014 at 12:39 PM, Luca Bruno <lethalma...@gmail.com> >> wrote: >> >>> I've launched this Zero Hydra Failures (ZHF) project. Details at >>> https://nixos.org/wiki/Zero_Hydra_Failures >>> >>> The hydra instance at nixos.org has lots of build failures, it's a huge >>> percentage over the total. The aim of this project is to drop failures to >>> zero. >>> >>> I invite all contributors to take some time reading the project page. >>> Trying to build a package, fixing or marking it as broken takes less time >>> that you might imagine. It's not as time-expensive as it would be for a >>> package that you are interested in. >>> >>> >> I'd like to float an alternative path. We know that the output of a >> successful build is a set of files. >> >> But what is the output of a failed build? >> >> I suggest that it should be a suggestion for a fix. When a build breaks, >> it shouldn't just stop dead. Rather, the build system should call an >> exception handler that over time could become pretty sophisticated. >> >> For example, for the failed python builds, this exception handler could >> check whether a successful build exists for another python version. If so, >> suggest a patch that blacklists the python version that was currently >> used. A general rule could be that if it builds successfully on another >> platform, blacklist this platform. >> >> These "suggestions" could be full-fledged git branches ready for a pull >> request, commits or just edits in a local nixpkgs tree. >> >> This is probably some work, but some perl hacks that work for certain >> regular nix expression layouts could potentially work for a lot of packages. >> >> To simplify auto-editing, a fairly strict syntax could be used for >> certain meta-data so that simple perl regexps + grep would be enough for >> most of the blacklisting/whitelisting work. >> >> Alexander >> >> >> >>> Best regards, >>> >>> >>> _______________________________________________ >>> nix-dev mailing list >>> nix-dev@lists.science.uu.nl >>> http://lists.science.uu.nl/mailman/listinfo/nix-dev >>> >>> >> > > > -- > www.debian.org - The Universal Operating System > -- www.debian.org - The Universal Operating System
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev