<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)) <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 <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 <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. <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. <vagrantc>it appears "WOnt" isn't actually in the guix source code. maybe a false positive. <pkill9>wish I understand why it needs the word store <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>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 ...)) <vagrantc>unable to guix pull ... running through all the commits to see when it started failing ... <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>what is bizarre is i can build those commits with guix time-machine just fine <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>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>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 :/ <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. <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>tried blaclisting both radeon and amdgpu but to no avail <efraim>sneek: later tell vagrant I'm going to miss authentification ***Dynom_ is now known as Guest235
***wielaard is now known as mjw
<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 <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>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>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? <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/libpthread.so.0: 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 <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 <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. <florhizome[m]>do icedove bugs go to guix or is there a gnuzilla mailing list 🤔 <jpoiret>Schmoho: can you try `LD_DEBUG=libs chromium` and paste the LD output? <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 source ~/.guix-profile/etc/profile in your shell and run emacs there <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/.../...") <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>i think it might actually need a new procedure in (guix build utils) <lechner>Does using list commit to using gexps? <two[m]>$ guix shell --container --development gnome-builder glib gtk pango@1.90.0 <two[m]>meson.build:298:0: 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>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 <nckhexen>Sure, standard (self-)quoting rules appyl if you squint a bit. <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>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. <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>when the #:import-path is at the start, it gets overridden by the #:import-path in arguments, which is "github.com/rfjakob/gocryptfs" 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 <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"? <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 <clever>but timezones then put half the world on december 31st 1969 <apteryx>gabber: I was to use the Guile API of Guix instead of the command line <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>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` <jeko>I ran the compilation in an environment generated with `guix shell gcc-toolchain` <jeko>indeed, did not fix the problem <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 <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? <nckhexen>vagrantc: That's mightily anti-imperialist of you. <f3n1x>hi guixers ! i've just installed miGuixPackage required for another emacsPackage. How can i get to know miGuixPackage path ? thanks, thanks, thanks <vagrantc>i am still baffled by the sneaky "This packages" in emacs-xyz.go <vagrantc>gah. still can't guix pull anymore. no version. <nckhexen>vagrantc: ‘This Emacs packages manages your Emacs kill-ring’ <emacsen>*grumbles something about hexchat notifications* <two[m]>nckhexen: remove pango from the manifest <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… <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 :) <f3n1x>thX , thX, thX unmatched-paren ! <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 <vagrantc>nckhexen: nice catch regarding This*packages in emacs-xyz :) <jeko>unmatched-paren: anyway, this seems not guix related so that's fine, I will look for help in the appropriate channel ;) <nckhexen>apteryx: So there is. Why the hell did it not show up. *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 ? <apteryx>no, it can be confusing. I think I've used "pango-next" name out of fears (or actual problem) of propagation clashes <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. <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 *vagrantc tries pulling from an older guix <f3n1x>uh, no..! i did not nckhexen , how to ? *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. <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! *f3n1x the referred package has freedom bugs <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 <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>but dangerously hidden such that i might forget to come back to it :/ <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 <vagrantc>changing comments in a package description shouldn't trigger a rebuild? <lechner>unmatched-paren: Hi, is it possible to run 'go test' inside guix shell --development --file=XXX ? I get errors like cannot find package "github.com/jacobsa/oglematchers" in any of: even though that's a native input <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 <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>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'