<brendyn>Hi civodul, may I bother you with a question that is probably in the manual but I can't see it: The package I'm definion doesn't have a `make install' phase, rather it just uses install -Dm755..., how can I implement that in Guix?
<civodul>interesting way to work around the bug :-)
<jmd>Now the source derivations occupy a lot of disk, but are not often accessed. Wheras, the build derivations are frequently accessed. I wonder if it would be possible to have them on different disks?
<ng0>make... -r, --no-builtin-rules Disable the built-in implicit rules. what does this do if an application sets this?
<ng0>I suspect it ignores everything I try to pass as makeflags, right?
<brendyn>guix refresh is extremely slow and dies after downloading a few package definitions. slowly making progress...
<brendyn>after the (add-before ... I'm adding a (replace 'install
<alezost>brendyn: cereal's 'install' phase have 'outputs' key. If you do the same, then % is not needed, but if it is not inside a phase (in #:make-flags, for example, as it is done in 'btar' package), then % is needed
<ng0>woah... first bitrot in my music archive after almost 20 years :/
<alezost>ng0: sure; about git-service: I don't have a clue on your VM question. But IIUC the git daemon is running, right? Then what's the problem? Can you test it without VM?
<alezost>brendyn: I think it's from 'copy-file': "praat" file is probably not in the root source directory
<ng0>no. because my system is not setup like that and probably never will be. That's why I need the qemu ports-forwarding
<brendyn>That's where it is when I compile it manually
<brendyn>I used -K so I should be able to investigate?
<ng0>the service is running, I only need to test a real life situation.. somehow
<alezost>brendyn: I think so, it is somewhere in /tmp
<ng0>if someone feels brave I can post an updated patch
<alezost>ng0: I've never used git daemon, and I don't have a wish to learn how to do it :-) But sure, please send a patch; if there will be no comments, I think it can be just pushed since the daemon is running
<alezost>sooner or later someone will try it and complain if it's not working properly, ISTR we have a couple of not-working services (network manager, maybe, I'm not sure)
<ng0>well it is rather easy to use. so damaged use will be visible early.
<ng0>how does one use network manager in guixsd? I've tried just adding it, but it conflicts with desktop-services
<alezost>ng0: I think it conflicts because %desktop-services already contain another service providing 'networking' (wicd)
<brendyn>ok so it's at /tmp/guix-build-praat-6.0.19-1.51c7b7b.drv-4/source/praat
<brendyn>Ok I'm still trying to grock inputs and native-inputs
<ng0>no stress.. it's difficult to get it all right at first :)
<brendyn>"The distinction between native-inputs and inputs is necessary when considering cross-compilation. When cross-compiling, dependencies listed in inputs are built for the target architecture; conversely, dependencies listed in native-inputs are built for the architecture of the build machine. "
<brendyn>It's bothering me that I haven't specified anything at all about architecture
<ng0>usually you don't.. you either know it, can read up on it or see a failed build on hydra and adjust accordingly. the default is to not specify anything architecture specific and assume that it just works
<efraim>linux-pam-1.3.0 broke shishi (a dependant of cmake) on core-updates. I got it worked out
<efraim>I should probably file a bug upstream with shishi
<rekado_>I'd like to make the CRAN importer more robust. I see that other importers don't print a backtrace when you try to import a package that doesn't exist, but the CRAN (and bioconductor) importers both do.
<rekado_>at what point are we supposed to catch download failures?
<rekado_>my instincts tell me: "where they happen", i.e. wrapping http-fetch
<rekado_>but other importers don't seem to do this.
<rekado_>also: I'd like to have this all wrapped in an Either monad, so that we don't need to take care of these things.
<rekado_>I could wrap the body of "fetch-description" in false-if-exception, but that seems like an application of the diaper anti-pattern.
<ng0>There is a question I want to answer in plain english for a readme file for the part which describes the guix ebuild. Is it nonsense to compile Guix instead of to just use the build binaries? Bootstrapping is explained, but the question I got from someone was more about security and reproducibility issues.
<davexunit>ng0: I don't think it's nonsense. I mean, Guix itself has Guix packages that compile Guix.
<roelj>If you want to have any guarantee that the code you can see corresponds to the binary that you run, then it makes sense to compile it yourself.
<ng0>it's not my own question.. the persons understanding is that Guix and Nix are not yet 100% reproducible and require some however insecure / not reproducible parts. no, the systems means NixOS/GuixSD in this case
<ng0>is this clearer? 'of course gentoo isnt reproducible, that's why it isn't even distributed with binaries. guix and nix however provide binaries of which most are reproducible, but not all . we would like to recompile those that cannot be rebuilt and would therefore make a good place for backdoors.'
<davexunit>what's the best practice for packages that need Qt these days?
<davexunit>are there modular packages that I should use?
<ng0>rekado_, what's your position on giving a short introduction talk to guix somewhere in berlin (cbase? onionspace? onionspace is something where people are often) and solving afterward questions which go beyond what's currently covered in the documentation? I feel very sad for the misinterpretations of each others side I read now and refuse to continue to play 'stille post'
<OrangeShark>brendyn: are you asking maybe for some sort of stable set of package definitions?
<davexunit>if you want someone else to be able to build *exactly* what you built, they need to use the same guix.
<brendyn>I'm just scared that this is going to hinder scalability
<davexunit>it enables scalability because we can change any part of the system that we need to.
<brendyn>I don't want exactly the same thing at all, I just want it to work
<davexunit>the only way to be *sure* that it will work is to use the same guix
<davexunit>in practice, I have my own custom package recipes that tend to keep working as-is despite all of the changes in guix
<brendyn>I'm not being picky for myself, I'm planning to go talk to teachers and principals about installing GNU/Linux, so we need a solution. Parabola doesn't seem all that viable to build something end-user friendly, and trisquel 8 is off to a slow start
<ng0>more or less yes. and I know that this is not kept on hydra for a reason. guess i wanted something which does not work for this - download source for easier build on the build machien which does not block the current machine