IRC channel logs


back to list of logs

<pkill9>how do you use the (@@ ...) import syntax? I'm trying to get process-actions from guix/scripts/package.scm
<pkill9>i get unknown location: source expression failed to match any pattern in form ((@@ (guix scripts package) process-actions))
<rekado_>where are you using this?
<pkill9>ah nvm I think I'm overcomplicating it again
<pkill9>it's a script that basically generates a manifest and runs guix package with it, I think I just need to export the manifest and then use the guix-package or guix-package* function
<pkill9>instead of trying to pass the manifest as a variable
<pkill9>export it as a file and use that like normal
<pkill9>so I guess my next question is, is there a function that takes a manifest object in guile and writes it to a file that the `guix package` command takes?
<pkill9>actually that wouldn't make sense
<lechner>florhizome[m]: yay!
<pkill9>the @@ works, just not on process-actions
***davii is now known as daviid
<pkill9>ahh it looks like build-and-use-profile is what I want
<rekado_>when a package “foo” has version “2.14a” then “guix build foo@2.14” will not work as a prefix
<rekado_>is this expected / intentional?
<pkill9>what do I provide to the store variable in build-and-use-profile? I seem to remeber there being something like %store in guix/gexp that gives it the current store or something, but not sure
<Luchadoritos>pkill9: Unsure myself. But it seems like you need to use (with-store store EXP) where you can use the store binding in EXP. Perhaps build-and-use-profile can go in the EXP.
<pkill9>what do i give it in 'store'?
<Luchadoritos>Seems like the word store. ,use (guix store) ,use (ice-9 pretty-print) (with-store store (pretty-print store)) seems to print a store-connection
<Luchadoritos>Without the with-store call, (pretty-print store) raises an exception.
<pkill9>wow it worked, thanks
<vagrantc>it appears "WOnt" isn't actually in the guix source code. maybe a false positive.
<Luchadoritos>Yay! Good job!
<pkill9>wish I understand why it needs the word store
<pkill9>I feel like I'm cargoculting
<Luchadoritos>It seems like (with-store store ...) Is a macro using (define-syntax-rule). The definition is in "guix/store.scm" if you want to venture into the repository and know about macros.
<Luchadoritos>Though on the manual, I do not find with-store. I found run-with-store in section 9.11 The store monad. Maybe that's the one you're supposed to use?
<pkill9>i'm not familiar with macros
<pkill9>but I hear they're powerful
<Luchadoritos>Haha me neither buddy
<pkill9>hmm run-with-store means I can't pass the 'store' variable to the function I'm calling, so maybe that's what it's for
<pkill9>ah I think with-store let's you change the variable
<pkill9>I have (with-store store (build-and-use-profile store ...))
<pkill9>and you can also do (with-store storrre (build-and-use-profile storrre ...))
<Luchadoritos>Ah, It's like a variable binding. Awesome!
<vagrantc>unable to guix pull ... running through all the commits to see when it started failing ...
<Luchadoritos>What's the error message you see?
<Luchadoritos>And by 'running through the commits' do you mean using 'guix system switch-generation'?
<vagrantc>no, i mean getting a list of git commits and running guix pull on each of them
<vagrantc>albbmwnqgm5dq5dgbbqw-guix-package-cache' build of /gnu/store/ks39hg0l6ywh1vkvishlj04bm72p2hzg-guix-package-cache.drv failed
<vagrantc>wow, my paste buffer refuses to paste the whole message
<vagrantc>the missing part was /builder for `/gnu/store/ks39hg0l6ywh1vkvishlj04bm72p2hzg-guix-package-cache.drv' failed to produce output path `/gnu/store/4kzxijv22l1w
<vagrantc>looks suspiciously like a missing or stray paren:
<vagrantc>what is bizarre is i can build those commits with guix time-machine just fine
<vagrantc>but not with guix pull
*vagrantc boggles
<Luchadoritos>If I run guix pull on my system I get no errors. My commit contains d3e982d. I had a previous error with guix and it was due to some critical files not containing the right definitions. In my case, guix gc did the trick.
<vagrantc>heh. you can pull the commit i pushed :/
<vagrantc>yeah, i gc'ed and no luck
<Luchadoritos>Guix gc --verify=contents,repair doesn't work?
<vagrantc>will try agian tomorrow, calling it a night :/
<Luchadoritos>Good night, and good luck in the morning. Hope the guix fairy blesses you.
<vagrantc>i tried the commit before with the same issue ... going to systematically run through them all and see if i can pull to anything ... but ... since you can pull it ... eesh.
<vagrantc>but that's work for computers to do
<vagrantc>not humans :)
*vagrantc waves
<vagrantc>although good reminder about guix gc --verify...
<the_tubular>I'm trying to boot guix in a vm and i'm getting a black screen :/
<the_tubular>Wow, nevermind it just took forever to boot
<Luchadoritos>How long? And what resources (CPU, memory, ssd vs hd) does your VM have access to?
<the_tubular>I'd say close to 10 minutes, it has 12GB ram and 4vcpu
<Luchadoritos>Crazy... Can't explain that one. Even my laptop was fast on boot.
<the_tubular>Even the installer UI is pretty slow
<lizog>hello guix, can i make `wireguard-service-type` not automatically connect when i perform `guix system reconfigure`?
<bitborealis>i am trying to run guix on my laptop, but the text after grub is not readable
<bitborealis>maybe a graphics driver issue ?
<bitborealis>tried blaclisting both radeon and amdgpu but to no avail
<bitborealis>( blacklisting them individually tbc )
<efraim>hello guix!
<efraim>sneek: later tell vagrant I'm going to miss authentification
<sneek>Got it.
<efraim>sneek: botsnack
<unmatched-paren>bitborealis: try adding ``nomodeset'' to the kernel args...
<bitborealis>unfortunately nomodeset seems to have no effect
<bitborealis>my GPU is an AMD Richland [Radeon HD 8650G] btw
***Dynom_ is now known as Guest235
<Lumine>Good morning #guix
***wielaard is now known as mjw
<PotentialUser-75>I am trying to install stumpwm, but failing
<PotentialUser-75> these instructions seem pretty dated
<PotentialUser-75>What else do I need to do besides include stump in config.scm? I don't quite know where to put the startx
<nckhexen>the_tubular: Silly question perhaps, but are you sure KVM is working?
<nckhexen>(Assuming the VM is the same architecture.)
<nckhexen>sneek: later ask vagrantc: Another reason to keep LICENCE is that it looks like a file name? Meaning, for once, that there might be an objective answer.
<nckhexen>bitborealis: 'Unreadable' sounds intriguingly distinct from 'invisible', which is the usual complaint.
<gabber>my universal-ctags gets shadowed by ctags from the emacs package. how do other Guix solve that issue?
<pkill9>really need to set up automatic updating on this machine
<pkill9>random bugs fixed all the time
<mroh>gabber: I have emacs in a profile and universal-ctags in a "devel" one, so I can call them with absolute paths (~/.guix-extra-profiles/profile/bin/...). Perhaps, you could make an (bash) alias to the ctags you need?
<jeko>Yooo Guixters !
<AwesomeAdam54321>Hello jeko
<jeko>I am trying to compile a C file… but I end up with
<jeko>`/gnu/store/r61db7qg3q9y291pvn7llcbkg9vph488-profile/include/stdlib.h:31:10: fatal error: stddef.h: No such file or directory
<jeko>   31 | #include <stddef.h>`
<jeko>AwesomeAdam54321 o/
<jeko>I am in a shell environment generated with `guix shell gcc-toolchain`
<gabber>jeko: can reproduce, not sure if another input is needed. what header do you include? stdlib.h?
<mroh>jeko: What is the code? "guix shell gcc-toolchain -- bash -c 'echo "#include <stdlib.h>" | gcc -x c -c -' " seems to work here.
<gabber>mroh: this fails for me too. i've seen this one before. is it possible guix and and the installed packages have diverged?
<mroh>weird. no idea.
<gabber>it works with `guix shell gcc-toolchain bash --pure -- bash -c 'echo "#include <stdlib.h>" | gcc -x c -c -'`
<mroh>maybe you have some gcc env or paths in your .rc/login files?
<gabber>mroh: i don't think i have such a thing specified manually, but i'm also not the original asker :)
<apteryx>hello Guix! Is it possible to use 'build-package' from (guix scripts) in a way to cause the build to use --check and --no-grafts?
<gabber>apteryx: is that different to `guix build --check --no-grafts` ?
<efraim>I feel like I got tricked into working on rust again. Moving a crate from crates-io to rust-apps and making it build, added almost 20 crates and it still doesn't build yet
<mroh>yeah, working on rust is like: you add zillions of deps and than at zillions-1 a pkg needs a newer version of x, rinse ,repeat...
<Schmoho>I am having a problem that is breaking guix as a secondary package manager for me
<Schmoho>chromium and the evolution mail client cant start, because they produce a
<Schmoho>symbol lookup error: /gnu/store/5h2w4qi9hk1qzzgi1w83220ydslinr4s-glibc-2.33/lib/ undefined symbol: __libc_pthread_init, version GLIBC_PRIVATE
<Schmoho>both chromium and evolution were installed via apt though
<Schmoho>does anybody know something about this? why this happens?
<gabber>Schmoho: what is the output of "ls -l `which chromium`"?
<lolzdev>hello, is there a reason why the startx command is looking for the X server binary in its store directory?
<gabber>lolzdev: yes, that's the Guix way
<lolzdev>I mean, in the xinit store directory
<lolzdev>obviously the X server binary isn't there
<lolzdev>should I specify the X server path in some way? it's the first time I try guix sorry if my questions seem dumb
<Schmoho>gabber: it's /usr/bin
<gabber>i suspect some kind of faulty environment. chromium seems to try to load libpthread from the store -- which is the wrong version for your /usr/bin/chromium.
<gabber>lolzdev: not sure i can follow. startx and xinit are built inside the xinit package -- hence these binaries are to be found there. what exactly are you trying to do?
<nckhexen>Schmoho: Is there anything suspicious in ‘env | grep -E '/gnu/store|guix'’, such as [LD_]LIBRARY_PATH??
<Schmoho>nckhexen: no LD_LIBRARY_PATH - what would be suspicious in general?
<efraim>sorry everyone, I'll fix master in a second, just need to see which commits to revert to not rebuild librsvg
<efraim>ok, it should be better now
<nckhexen>Schmoho: I'm not quite sure (I was expecting an obvious $LIBRARY_BAD_THING to be honest).
<nckhexen>You could just share the output & maybe something will jump out at someone.
<nckhexen>( pleeze.)
<florhizome[m]>do icedove bugs go to guix or is there a gnuzilla mailing list 🤔
<AwesomeAdam54321>florhizome[m]: The GNUZilla mailing list
<jpoiret>Schmoho: can you try `LD_DEBUG=libs chromium` and paste the LD output?
<nckhexen>Ooh that sounds nice.
<lolzdev>what I have to do to let emacs find the packages I installed with guix package manager?
<unmatched-paren>lolzdev: log out and log back in, if it's your first time installing emacs packages
<unmatched-paren>or use a new login shell to launch emacs
<unmatched-paren>or source ~/.guix-profile/etc/profile in your shell and run emacs there
<unmatched-paren>...oh. they just left.
<lechner>never liked that feeling!
<sneek>podiki[m]: Greetings!
<florhizome[m]>geary doesn't start, the Error seems to be having two different versions of libsoup available. I guess this comes via normal webkitgtk in goa
<StefanCristian>hello. does guix have any chroot I can play with? or just install and extract rootfs
***mark_ is now known as mjw
<gabber>StefanCristian: i'm not sure what exactly you mean by that, but you can take any system configuration and `guix system vm config.scm`
<StefanCristian>gabber: what I mean is that if there's any minimal filesystem tar.xz that I can use to just chroot into, without the need to install the system, while using any other Linux
<two[m]><StefanCristian> "gabber: what I mean is that if..." <- yes, it's third on the download page
<two[m]>but if you're using debian you can do sudo apt install guix
<gabber>StefanCristian: if you just install Guix (not the whole system) then you can use the `guix system vm` command from before
<two[m]>gabber: this starts a qemu window, not a chroot
*unmatched-paren still trying to figure out how to turn a list of search-path-specifications into a list of ("NAME=/gnu/store/.../...:/gnu/store/.../..." "NAME=/gnu/store/.../...:/gnu/store/.../...")
<unmatched-paren>(inside a gexp)
<gabber>unmatched-paren: does NAME correspond to the variable field? there's search-path-specification->sexp and search-path-specification->code but i guess that's not what you're looking for?
<unmatched-paren>gabber: yes, to the name of the env var
<unmatched-paren>i think it might actually need a new procedure in (guix build utils)
<lechner>Hi, this is a build-side question. Why does an explicit 'list' here (instead of the quote) trigger warning: 'replace' may only be used within 'modify-inputs' please?
<lechner>Does using list commit to using gexps?
<two[m]>i have this shell
<two[m]>$ guix shell --container --development gnome-builder glib gtk pango@1.90.0
<two[m]>but meson build gives
<two[m]> ERROR: Could not generate cargs for gtk4:
<two[m]>Package 'gtk4' requires 'pango >= 1.50.0' but version of pango is 1.48.10
<nckhexen>lechner: Probably because you didn't gexp modify-phases?
<nckhexen>And hence it's being called (way) too early.
<lechner>i see
<lechner>if gexp is on the build side, which side am i on, please"
<nckhexen>As a rule, the migration pattern is '(#:stuff (foo …) → (list #:stuff #~(foo …))
<nckhexen>lechner: The ‘host side’, basically the context of the guix command itself.
<unmatched-paren>#~... should not, however, be used if the value is a string, number, or other constant
<unmatched-paren>or with #:modules
<nckhexen>Sure, standard (self-)quoting rules appyl if you squint a bit.
<lechner>nckhexen unmatched-paren: thanks!
<nckhexen>two[m]: That profile contains both pangos (include/pango-1.0 and include/pango-2.0) and your package's build system isn't clever enough not to pick the wrong one, I guess. I didn't check why both pangos are in there.
*nckhexen AFK.
<nckhexen>Oh, it's also probably not helping that it's likely to be looking for ‘pango 1.x’, while you're trying to build it against what looks like a pango 2.x prerelease, so it might not even ‘see’ it.
<lechner>Hi, why does this Gexp conversion not perform like the original, please? (Only the first folder is processed.)
<unmatched-paren>maybe try (apply (assoc-ref %standard-phases 'build) (cons* #:import-path directory arguments))
<two[m]><nckhexen> "two: That profile contains..." <- how do i remove it?
<lechner>unmatched-paren: thanks, but unfortunately not working
<lechner>does the #:import-path have to be quoted?
<unmatched-paren>maybe try that, yeah
<unmatched-paren>does (append arguments (list #:import-path directory)) work...?
<unmatched-paren>aha, yes, that'll be it
<unmatched-paren>when the #:import-path is at the start, it gets overridden by the #:import-path in arguments, which is "" of course
<lechner>unmatched-paren: yay! thanks so much!
<lechner>unmatched-paren: Why is #:import-path overridden otherwise, please?
<unmatched-paren>lechner: i guess guile prioritises keywords further towards the end of the procedure call
<lechner>unmatched-paren: thanks! is there a way to pass these extra -X arguments to the golang build system, please?
<unmatched-paren>lechner: yes; i do it in aerc, you need to use #:build-flags #~(list ...)
<lechner>unmatched-paren: where may i find the packaging for aerc, please?
<lechner>unmatched-paren: woohoo! with your help i am nearly done with my first Guix package
<lechner>Hi, is there something better to use for a reproducible build date than the string "today"?
<unmatched-paren>lechner: 1970-01-01 ;)
<clever>lechner: nix/nixos uses a unix timestamp of 1 (1 second after the above date), because some programs are silly and think a timestamp of 0 is an error
<lechner>unmatched-paren clever: there is this concept
<clever>but timezones then put half the world on december 31st 1969
<unmatched-paren>lechner: yeah, guix uses that
<unmatched-paren>but of course not every build system supports it...
<lechner>i see
<apteryx>gabber: I was to use the Guile API of Guix instead of the command line
<apteryx>trying to*
<apteryx>build-package from (guix scripts) is an API equivalent(ish) to 'guix build'
<lechner>unmatched-paren: in my case, the build system does not need to support it, i do not think, as long as i could get a commit timestamp from git-fetch
<gabber>apteryx: this might not be the thing you're looking for, but (guix-build "hello" "--check" "--no-grafts") inside a guix repl (with a use-module for (guix scripts build)) does the trick ;)
<jeko>Yo Guixters !
<tricon>howdy, jeko.
<jeko>tricon o/
<unmatched-paren>heya! :)
<jeko>unmatched-paren: yoo !
<jeko>I am playing with a bit of C code right now and I am stuck with `/gnu/store/r61db7qg3q9y291pvn7llcbkg9vph488-profile/include/stdlib.h:31:10: fatal error: stddef.h: No such file or directory`
<unmatched-paren>that's very strange
<unmatched-paren>they should both come from the same package
<unmatched-paren>(glibc, of course)
<jeko>I ran the compilation in an environment generated with `guix shell gcc-toolchain`
<jeko>should I add glibc ?
<lechner>i'd try that
<unmatched-paren>yeah, probably
<unmatched-paren>wait, no, gcc-toolchain includes glibc...
<jeko>indeed, did not fix the problem
<two[m]>with --export-manifest all i get is... (full message at <>)
<jeko>A simpler gcc command did compile the file so it definitely comes from my options haha crap…
<two[m]>$ guix shell guile guile-readline -- guix repl --type=list
<two[m]>guix repl: error: list: unknown type of REPL
<two[m]>$ guix shell guile guile-readline -- guix repl --type=help
<nckhexen>‘info (guix)Invoking guix repl’, but yes, that could be added to --help or --type=list as well.
<vagrantc>someone has managed to taunt me by sneaking a "This packages" into I: guix: spelling-error-in-binary "This packages" "These packages" [usr/lib/x86_64-linux-gnu/guile/3.0/site-ccache/gnu/packages/emacs-xy
<sneek>Welcome back vagrantc, you have 1 message!
<sneek>vagrantc, nckhexen says: Another reason to keep LICENCE is that it looks like a file name? Meaning, for once, that there might be an objective answer.
<vagrantc>z.go] but it doesn't even appear in the source anywhere
<lechner>jeko unmatched-paren: maybe this?
<vagrantc>the only occurence of "This packages" in the source is lint.scm and the corresponding tests
<vagrantc>nckhexen: i just have lintian override all occurrances of LICENCE|Licence|licence now, as ... it's not really a mispelling.
<nckhexen>two[m]: <how do I remove it> Remove what, and why?
<vagrantc>think it might even be en_US vs. en_UK
<nckhexen>vagrantc: That's mightily anti-imperialist of you.
<nckhexen>vagrantc: Yes.
<vagrantc>nckhexen: by listing two empires? :)
<f3n1x>hi guixers ! i've just installed miGuixPackage required for another emacsPackage. How can i get to know miGuixPackage path ? thanks, thanks, thanks
<nckhexen>Is was joke.
<vagrantc>i am still baffled by the sneaky "This packages" in emacs-xyz.go
<vagrantc>maybe it's a trusting trust attack!
<vagrantc>gah. still can't guix pull anymore. no version.
<nckhexen>vagrantc: ‘This Emacs packages manages your Emacs kill-ring’
<nckhexen>It should be Emacsen packages.
*vagrantc smiles
<vagrantc>oh, nice.
<emacsen>*grumbles something about hexchat notifications*
<two[m]>nckhexen: remove pango from the manifest
<unmatched-paren>f3n1x: you mean its /gnu/store path? ``guix build <pkg>''
<two[m]>that i get from --development gnome-builder
<vagrantc>emacsen: surely you pick your poison? :)
<nckhexen>two[m]: You're adding it on the command line…
<emacsen>vagrantc :)
<nckhexen>two[m]: You need to package pango >= 1.50 (or whatever it was), then use that.
<emacsen>vagrantc, true nuff. My cat Ascii has it much worse in that regard, but she's not on IRC :)
<nckhexen>1.90 is very likely not >= 1.50.
<f3n1x>thX , thX, thX unmatched-paren !
<jeko>unmatched-paren: I am pretty sure all the necessary options are specified… for the reccord, I am trying to compile using
<two[m]>nckhexen: it is packaged
<two[m]>but that imports an older version
*nckhexen just shrugs when people with generic nicks get pinged. Choose a memorable nick like jffsdf or nckx instead.
<nckhexen>two[m]: Package pango, not gnome-builder.
<nckhexen>two[m]: Package 'gtk4' requires 'pango >= 1.50.0' but version of pango is 1.48.10
<nckhexen>Guix has no pango >= 1.50.0.
<vagrantc>nckhexen: nice catch regarding This*packages in emacs-xyz :)
*nckhexen bows.
<jeko>unmatched-paren: anyway, this seems not guix related so that's fine, I will look for help in the appropriate channel ;)
<apteryx>nckhexen: there's pango-next
<nckhexen>apteryx: So there is. Why the hell did it not show up.
<two[m]>$ guix show pango@1.90.0... (full message at <>)
*vagrantc hunts some "allows to"
<apteryx>nckhexen: it has the "pango-next" name
<nckhexen>I've said two[m] times above thatthat 1.90 is unlikely to be >= 1.50.0.
<f3n1x>well, unmatched-paren , the given emacsPackage by default expects miGuixPackage in '/usr/local'. As per your suggestion i've found that it is in '/gnu/store/4m08looonghassshere-myGuixPackage' ... is that one to be used instead of ?
<nckhexen>apteryx: Ah, because I am an idiot.
<nckhexen>two[m]: pango-2.0 != pango-1.0 series.
<apteryx>no, it can be confusing. I think I've used "pango-next" name out of fears (or actual problem) of propagation clashes
<unmatched-paren>f3n1x: yes
<nckhexen>two[m]: pango-next is probably what you want then.
<vagrantc>guix-package-cache will not build for me anymore. on any commit. WAT.
<two[m]>tthank you
<nckhexen>apteryx: I'd expect the variable to be called pango-next, but not the package, but this is probably subjective.
<apteryx>same-named packages clashes with an error when put in the same profile
<nckhexen>It's extra bad that ‘guix build pango’ builds a newer pango than ‘guix build pango-next’.
<f3n1x>well, i've just tried, and it doesn't work... as long as emacs is complaining about with error messages like 'make -C server clean... command not found" and bla. What am i missing ?
<f3n1x>as long as *** [Makefile:35: emacsPackage] Error 127
<two[m]>is libpanel not packaged?
<nckhexen>f3n1x: Did you patch out the /usr/bin?
*vagrantc tries pulling from an older guix
<f3n1x>uh, no..! i did not nckhexen , how to ?
<f3n1x>thanks, thanks, thanks !
*f3n1x guix obvious newbie here ...
<nckhexen>I didn't follow your entire thread, but one would usually use (substitute* "Makefile" (("/usr/bin/") "")), but it really depends.
<f3n1x>well, the thing is that i need to tell an emacsPackage where is the required miGuixPackage library for.
<nckhexen>What is ‘an emacsPackage’?
<nckhexen>Why doesn't it just use $PATH?
<f3n1x>ah! dunno... i just know what that Emacs package i've just installed was expecting a required package in '/usr/local' (typically on non Guix systems), and i need configure this patch. May use $PATH for ?
<nckhexen>f3n1x: ‘Error 127’ here means the Makefile is trying to run a binary but can't find it. It does not look like a library issue or even an emacs issue, from this distance.
<nckhexen>Ah, you even said ‘command not found’ before that, so yeah.
<nckhexen>sneek: later tell f3n1x: Unless the Emacs package has freedom bugs, please share the package so people can give concrete advice. TTYL!
<sneek>Got it.
*f3n1x the referred package has freedom bugs
<two[m]> - error?
<Luchadoritos>vagrantc: Checking up on your previous problem. Did you have any insights after your break from bug fixing?
<vagrantc>Luchadoritos: well, i used an older guix to pull a copy of current guix into it's own profile ... and then used that to pull guix in my usual guix pull profile ...
<vagrantc>might have been able to skip the middle step, but was in the middle of pulling
<vagrantc>curious if someone could reproduce the issue with bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f and fail to pull to a newer version
<Luchadoritos>Ooh. Did it pull to completion?
<vagrantc>Luchadoritos: by *not* using bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f, i was able to get up to current guix master.
<vagrantc>don't know that bb2701b9111a3d82a82ceaaf2b22b51ecd8ac21f was the commit that caused the problem of if earlier ... but was there a way to mark bad commits?
<Luchadoritos>vagrantc: Hooray!! Bug gone! Now that we have less 'on the line' we can inspect the commit more deeply.
<vagrantc>not gone, just worked around
<vagrantc>but dangerously hidden such that i might forget to come back to it :/
<vagrantc>time travelers beware
<vagrantc>i've got important things to do, like typo fixes :)
<Luchadoritos>This is computer triage, first get the computer to work, then do the real bug fix. Should be smooth sailing from here though.
<tricon>Luchadoritos: what a nick! hah! i love it.
*vagrantc wanders off to engage with meatspace
<Luchadoritos>tricon: :)
<jeko21>See you all ! take care
<vagrantc>changing comments in a package description shouldn't trigger a rebuild?
<vagrantc>sneek: botsnack
*vagrantc waves
<lechner>unmatched-paren: Hi, is it possible to run 'go test' inside guix shell --development --file=XXX ? I get errors like cannot find package "" in any of: even though that's a native input
<unmatched-paren>lechner: that's odd
<unmatched-paren>sorry, i'm not too sure what's going on there
<unmatched-paren>lechner: actually, now that i look at that gocryptfs package again, i think you can get rid of (replace 'build ...) if you do (delete 'build) and #:tests? #f...
<lechner>i'll respond in a couple of hours. crossing guard duty
<lechner>meanwhile, you could try on top of a cloned go-github-com-jacobsa-ogletest if you care
<unmatched-paren>or, actually, use (replace 'check (lambda* (#:key tests? import-path #:allow-other-keys) (when tests? (with-directory-excursion (string-append "src/" import-path) (invoke "bash" "test.bash")))))
<unmatched-paren>instead of #:tests? #f
<unmatched-paren>lechner: oh, silly me; you can't use guix go packages anywhere but in a guix build environment
<unmatched-paren>there needs to be a specific fs layout for it to work (which go-build-system sets up)
<apteryx>would someone be interested in a '--with-mappings' switch for 'guix shell --container'?
<apteryx>or perhaps just --symlink, it'd work the same as for 'guix pack'
<apteryx>with an example use case: 'guix shell --symlink=/usr/bin/env=bin/env'