IRC channel logs

2014-10-26.log

back to list of logs

<jmd>Hydra is broken again?
<phant0mas>good morning guix
***DusXMT_ is now known as DusXMT
<jmd>Why do some packages have #:out-of-source? #t and other not ?
<mark_weaver>some packages require that the build is done outside of the source directory.
<mark_weaver>icecat-31 is one example that's fresh in my mind.
<DusXMT>nVi also needs it, since building it in the extracted folder clashes with existing directories
<DusXMT>ie. there's a folder called `vi' and an executable to be built called `vi'
<DusXMT>and gcc, while I think it can be built in the source directory, also has its documentation recommending it to be built outside.
<DusXMT>so why not enable it everywhere? Well, as it turns out, a lot of projects don't build out of source, so it's easier to make it false by default.
<DusXMT>s/don't/fail to/
<mark_weaver>riht
<mark_weaver>right
<siddhanathan>does anyone have any input on nix vs guix? how are they related, and what differences do they have?
<jmd>siddhanathan: I don't know nix, but I think the primary difference is that nix uses a special purpose language whereas guix a standard one.
<DusXMT>siddhanathan: they use the same backend (nix daemon, derivations), but different front-ends and languages (nix uses its own language for defining configurations and packages, guix uses Scheme), In Guix we mostly try to run tests of packages, while in Nix, they are mostly disabled by default
<viric>about tests, I don't agree
<DusXMT>and there are also some differences in the systems provided by the package managers, for example, GNU, the only distribution using Guix as its package manager, comes with dmd as its init daemon
<viric>that's more about nixos/gnu, not nix/guix
<DusXMT>viric: my information might be old, so it's possible
<viric>nix (language + backend). nixpkgs (package definitions for nix). nixos (a bootable OS built and managed by nix, using nixpkgs)
<jmd>I wonder which has more packages these days?
<DusXMT>I bet nix, but haven't actually checked
<DusXMT>since it's been around longer, I'd assume that
<viric>nixpkgs has ~ 6475 .nix files for packages
<viric>one nix file per package is a good approximation I think
<SylvieLorxu>Wait, dmd
<SylvieLorxu>Oh gosh, GNU Guix may very well be my escape from systemd
<siddhanathan>Thanks for the input. I'll give guix a try soon :)
<viric>I hope the guix community exploits the current scenario where people are ready to switch distribution just to go away from systemd
<jmd>A quick count shows that 186/980 packages have #:tests? #f
<jmd>(which is too many IMO)
<viric>comparing this with nixpkgs with % would not be a fair comparison though
<viric>the amount of packages is quite different
<jmd>can nix cross compile packages?
<viric>nixpkgs has pieces to cross build, yes
<viric>I wrote them :)
<viric>(or the most part)
<viric>since more or less 2009
<davexunit>jmd: a bunch of test suites aren't written very well.
<jmd>davexunit: Yeah, but almost 20% of them ??
<SylvieLorxu>"I hope you can agree that the latter solution after all is the best one, because we can be sure to not do something that the user does not want us to do. Software should not run amok" and "I see few reasons to make the source code of dmd more complicated than necessary" make dmd already feel a lot safer than systemd to me. I should figure out how to fix network in virt-manager so I can really try GNU Guix
<DusXMT>jmd: some packages don't even have the make check rule
<viric>I never wrote a make check rule for my software :)
<davexunit>DusXMT: yes, that's another important point.
<jmd>DusXMT: True, but again I doubt that 20% of them are like that.
<DusXMT>viric: as in, $ make check # fails on because of a no rule fault
<davexunit>jmd: http://paste.lisp.org/display/144170
<davexunit>you will that many of them have no tests
<davexunit>you will see*
<davexunit>of course, I agree that as many packages as possible should have a passing test suite.
<viric>DusXMT: I know very well :)
<davexunit>that would be a good project for someone :)
<jmd>We should canonicalise that comment, so we can count them easier.
<davexunit>the canonical one is 'no check target'
<davexunit>at least that's what ludo, myself, and some others use
<jmd>Probably not the best one. Some packages call is something else.
<jmd>/s/is/it
<davexunit>it's 'check' in the gnu build system. we could generalize to 'no tests', but 'no check target' or whatever is more descriptive.
<jmd>"no test suite" would seem concise yet unambiguous.
<jmd>For example, aegis calls its test target "sure"
<davexunit>yeah, that would be fine
<jmd>We really need a recommended-inputs field.
<jmd>Bed time