<rain1>hm how do you approach the import problem? golang just points to a git repo, not to a specific commit
<lfam>rain1: If I end up doing the work, I'll use Syncthing as the test package for the build system. It has a few dozen dependencies, some of which have their own dependencies, and the Syncthing project specifies which Git commit they build each dependency form
<lfam>Honestly, I still don't fully understand how Go programs are supposed to be built. I keep reading things like "golang just points to a git repo, not to a specific commit" and ask myself, "Really? That doesn't seem right"
<lfam>But then I talk to Go programmers about this and they all get this dark look and start sighing
<lfam>It doesn't make sense to me that the idiomatic build system for a new language just pulls the latest commit of a development repo
<reepca>lfam: perhaps they expect a non-development repo?
<lfam>I guess saying "development repo" was needlessly derogatory ;) They must expect rock-solid master branches
<lfam>Well, lots of things are written in Go, so it must work out somehow
<OriansJ>janneke: thank you for the patch, I've also made some interesting developments with META II
<reepca>Looking through gnu/packages/python.scm, I notice that most of the sources are in .tar.somecompressionformat form, and yours is in .zip form. A quick search reveals that python-pytest-mock, for example, also downloads something in .zip form, and it uses "unzip" as a native-input.
<reepca>Builds are done in an isolated environment, so you have to explicitly tell it to make unzip available
<reepca>(apparently that's not an implicit input from python-build-system I guess)
<sneek>m-o, civodul says: you could do (dynamic-func "scm_run_finalizers" (dynamic-link)) and use the FFI
<fps>nalaginrut: you can just enumerate all packages, and then write a for loop that calls guix package -i <package> --fallback or something
<fps>takes on the order of a couple of days possibly
<efraim>With grafts you have to build the packages with --no-grafts for --keep-going to work
<efraim>I also run a guix-publish service on one of my aarch64 boards
<jsierles>is there a way to use a manifest, or something like 'guix package -p' with 'guix pack'?
<jsierles>what does this mean? warning: collision encountered: /gnu/store/s45c3nf4swhkgwrsc7bbnp3abhik2wwd-gfortran-7.1.0/libexec/gcc/x86_64-unknown-linux-gnu/7.1.0/install-tools/mkheaders /gnu/store/yr9rk90jfpq7xcbh24aryrnsd2i3qvwa-gcc-toolchain-7.1.0/libexec/gcc/x86_64-unknown-linux-gnu/7.1.0/install-tools/mkheaders
<jsierles>not clear if this conflict is something i need to worry about.
<roelj>Is there a way to use a package in a G-Expression, that needs its propagated-inputs to function properly? I see that the propagated inputs are not in the package's output path, so using a G-Expression, it's missing crucial bits to run a program in the package.
<roelj>This will not work: (system (string-append #$r "/bin/Rscript my-script-that-needs-r-genomicranges.R"))
<rekado_>roelj: that’s because you don’t have a profile at this point, right?
<rekado_>I’m still waiting for IT to perform a few more changes
<rekado_>once that’s done I’m free to test the performance impact of that commit
<roelj>I have that commit applied. For 'time guix environment --ad-hoc coreutils --pure --no-substitutes --no-grafts -- true', the timings are like this: 55.702s, 28.124s, 23.728s, 18.530s, 17.294s, 16.819s, 16.374s, 21.436s.
<roelj>So, the first time always takes much longer (due to NFS caching I guess). And the other timings look like an improvement
<jsierles>rekado_: in your R article, you suggest a technique for still supporting install.packages. however since R_LIBS is set to the store, doesn't that mean R will try to write there?
<ryanwatkins>Hey guys, is there any reason why I might have trouble running binary files on GuixSD?
<ennoausberlin>Hello. I played around with configurations and after bare bone install I decided to add X support. Most packages are installed but the X binary is not there. How can I find which package is related to that file? guix package -s X gives me too many hits
<ennoausberlin>I dont need the full gnome desktop. So I just wanted a X server and clfswm or stumpwm as window manager
<jsierles>is there a way to list available packages, including those available in GUIX_PACKAGE_PATH?
<jsierles>found it - guix package --list-available.
<OriansJ>janneke: today there should be another few hundred more M0 definitions for x86 opcodes, I hope to have all the ones you need before the end of the day
<rekado_>jsierles: R will offer users to install to a directory that they can write to.
<rekado_>jsierles: I’m using a slightly more complicated profile for users in my research group
<janneke>OriansJ: ow...what an amount of work! do i need that much?
<rekado_>jsierles: maybe your experiments can help us identify some of the open questions in implementing channels.
<OriansJ>rain1: well it answers the question of how gcc got that number, 128MB of stack space with the stack below the code growing down.
<OriansJ>rain1: I honestly don't get those two design decisions: stack growing towards zero and defining a standard stack base address which explicitly prohibits the largest and fastest growing part to only 1/32 of the address space