<ison111>mange: With that it says invalid input "go". It's alright though I don't mean to cause you trouble. I can wait for the default to update to version 1.10 or maybe play around with it myself later.
<mange>Can you paste the definition you're trying with the link in the channel description?
<mange>Basically what I did is remove the "go" input (because it will be added implicitly by the build system), and change the string "go-1.10" to instead put the go-1.10 package object into the arguments (which requires using , to unquote it).
<mange>That builds on my machine, so hopefully it will build for you.
<mange>It doesn't run for me, though, but I'll leave it to you to work out why.
<lfam>mange, ison111: The go-build-system will work with Go 1.10, but less efficiently than with Go 1.9. No news yet about Go 1.11
<lfam>mange: In Go 1.10, the method used by the Go compiler to determine when a dependency needs to be rebuilt was changed. Guix's go-build-system hasn't been updated to handle this, so every Go-language dependency will be rebuilt for each package. No compiled objects are re-used
<lfam>The new technique is called "content-based staleness", if you'd like to read about it. On the surface it's basically the same thing as Guix, a memoized cache of compiled objects
<apteryx>anyone having issues with guix offload on recent guix?
<ecbrown>apteryx: yes, i have the same issue, some machines that do work, some don't. i see references to /usr/local/etc/guix/machines.scm iirc. i could swear that the machines are set up similarly, though i have not been systematic otherwise i'd be able to fix it/make a good bug report.
<ecbrown>i think i have a system that builds remotely, but guix offload test doesn't work
<janneke>until gettext-boot0 there are no differences; i rewrote all earlier packages from using `package-with-explicit-inputs' to (arguments (#:implicit-inputs #f ...
<janneke>did that mainly to check if there is a problem with package-with-explicit-inputs, and that seems the case
<janneke>i could rewrite the remaining bootstrap packages too and we could remove package-with-explicit-inputs, or package-with-explicit-inputs could be fixed and the other rewrites can be reverted. WDYT?
<civodul>janneke: seems to me that we should fix package-with-explicit-inputs
<civodul>if you look at the child process, its argv is the PID of the client
<apteryx>interesting; I didn't know that using 'guix environment' spawned a guix-daemon instance.
<civodul>'guix environment' opens a connection to the daemon, which spawns a child process to handle it
<apteryx>I see. Thanks for the explanation! strace is helpful again now that I'm tracking the right guix-daemon :)
<apteryx>I'm struggling a bit with guix offload again, on one machine :/. It was working fine until I updated guix on it recently. Strange thing is that doing 'guix offload test /etc/guix/machines.scm 127.0.0.1' to test it result in *zero* activity in either my or the remote machine's guix-daemon. It fails with: http://paste.debian.net/1042776/
*janneke goes to play with new learned guix repl skills to try create more insight into his own bug-32749
<janneke>...but still flabbergasted--package-inputs, package-native-inputs, package-propagated-inputs do not reveal anything interesting
<civodul>apteryx: could it be that guile-gcrypt isn't in GUILE_LOAD_PATH on the target machine?
<civodul>unfortunately the ~/.config/guix/current profile doesn't propagate it
<myglc2>Hi #guix! avahi stopped working after recent 'guix system reconfigure'. E.g., host g1.local gone but var/log/debug contains "avahi-daemon: Server startup complete. Host name is g1.local. Local service cookie is 1956729094." shows '.
<davexunit>I'm just going to stick to a combination of graph paper and winging it, though.
<davexunit>I'v been taking a woodworking class where all the projects were designed in sketchup and the source files are provided in case you want to make edits. I have no desire to write something capable of loading sketchup files but I wish someone would!
<lfam>thorwil: I'm a little confused about the shebang issue. It should be handled by the gnu-build-system's bootstrap phase. Does your package definition use the gnu-build-system? Does it override the built-in bootstrap build phase?
<lfam>As for the gettext warnings, you might try adding gettext-minimal to the build environment
<thorwil>lfam: yes, (build-system gnu-build-system), no overrides yet, as i have no clue whyt may be necessary
<lfam>thorwil: My first read of your paste was pretty loose. I'm not sure how exactly to interpret the line with the shebang error. Is autogen.sh running configure in the bootstrap phase?
<lfam>If 'configure' already exists, it's probably not necessary to bootstrap
<thorwil>lfam: seems to me phase 'bootstrap' starts with autogen, then configure. no other phase entered
<lfam>thorwil: The gnu-build-system phases go like this: [...] bootstrap, patch-usr-bin-file, patch-source-shebangs, configure [...]
<ng0>since i started working more focused on my own thing with a different layout it's easier.. i just have one guix branch and apply code when I send it to guix :) i still have a huge backlog of the over 70 branches.