IRC channel logs


back to list of logs

<graywolf>omfg; the grep package *should* support -P, it just does not due to bug in our packaging
<graywolf>Aaaaand it is fixed on core-updates
<graywolf>I need to learn to check core-updates first before debugging anything. This is second multi-hour debug session due to something already fixed on core-updates...
<graywolf>In past week
<sadie_>hello! i'm trying to define a package for Leiningen. losing my mind a little because `invoke` claims it cannot find a build script that i'm very confident is there. what might i be missing here?
<peanuts>"debian Pastezone"
<sadie_>i've tried relative and absolute paths, as well as `chmod +x`'ing it
<weary-traveler>sadie_: lein as a file exists and is executable, but invoke complains?
<weary-traveler>odd. what happens when you try and invoke the equivalent command manually in a derivation checkout?
<weary-traveler>or whatever it's called when guix saves the directory containing a failing derivation
<sadie_>just calling the file in a normal shell? that does work as expected
<weary-traveler>well in a shell that has the build environment akin to what's there when guix builds
<sadie_>ooh! i had the builder create the output directory and copy the binary there, letting me into a `guix shell`. running it from there clarifies the "no such file or directory" refers to /usr/bin/env rather than lein
<sadie_>ta for the advice
<weary-traveler>np; going into a shell with guix environment is quite handy for debugging. using -K flag, guix build keeps directories of failed builds. said directories contain an environment file that can be sourced to get an approximation (?) of guix's environment during build
<apteryx>weary-traveler: you get same deps with '. enviromnent-variables' inside a failed build; you don't get any isolation from the rest of the system / network, so /bin/sh exists, unlike in the build container.
<apteryx>to get closer to the real thing, I sometimes use 'guix shell -CD the-package', and inside the containerized environment, I do 'rm /bin/sh'
<apteryx>it's still not exactly the same, as this generates a *profile*, while in the build environment there are none.
<apteryx>but in practice it's usually close enough to reproduce all issues.
<weary-traveler>i see
<weary-traveler>that's informative; thanks
<apteryx>you're welcome
<weary-traveler>apteryx: thoughts on that being "guix shell -CD $foo" vs "guix shell -CPWD $foo"?
<adanska>Hi Guix!
<futurile>Morning all
<futurile>hmm is having a bad morning - I can't get it to load
<efraim>the patches are loading for me
<efraim>I should probably take a look at some of the riscv64 patches, it'll take my mind off the ~200 rust patches I'm still catching up on
<efraim>what I really need to do is get etc/committer.scm working on rust packages. I spent ~30 minutes this morning manually typing out about 65 patches. Even straight forward I can only do about 2 a minute
<ngz>Speaking of rust-team, I wanted to refresh some Rust packages, starting from that branch. I created a worktree for it, entered the directory, and ran the bootstrap and configure dance. However, I'm not sure how I can build stuff from there. In particular, "./pre-inst-env guix build rust-whatever" seems to build from regular tree. What do I need to do?
<efraim>sounds like you might've skipped the 'make' step
<ngz>It sounds like so, indeed.
<ngz>OK, let's burn a few CPU cycles.
<efraim>make sure you pull, I just pushed a bunch of patches today
<ngz>OK, thanks for the heads up. I'm not planning to work on it right now, tho.
<lechner>sneek / later ask rekado / Hi, what would it take to add password or CertFP authentication to guile-irc, please?
<lechner>sneek / later ask janneke / Hi, does your guile IRC thing support authenticating nicks?
<sneek>Got it.
<janneke>lechner: snuik only has password authentication when it connects
<sneek>Welcome back janneke, you have 1 message!
<sneek>janneke, lechner says: / Hi, does your guile IRC thing support authenticating nicks?
<janneke>sneek: botsnack
<lechner>janneke / i don't think guile-irc offers any authentication
<erikeah>Good morning everyone,anyone in charge, could review my patch, it's been open for more of a month and no feedback has been given. Thanks!
<lechner>erikeah / which bug, please?
<peanuts>"[PATCH] gnu: Add sandbar."
<lechner>janneke / rekado / never mind. i'm so dumb. I can just IDENTIFY!
<wingo>is there a way to easily rebuild a package with different cflags? e.g. -O0 -g instead of the default -O2 -g
<wingo>i got a segfault in gdb, so i ran "gdb gdb ..." -- but the resulting backtrace doesn't have enough info because gdb was compiled with optimization
<wingo>i would really like it if guix could drop me in an env to hack on any given package. let it use that local checkout (with guix patches applied etc) as the source for the package to be compiled
<wingo>but, already it would be nice to have a guix build -O0 option
<wingo>or guix build --extra-configure-args="CFLAGS='-Og -g'" or something
<futurile>wingo: yes, it's a transformation that you can apply to guix build: guix build mutt --with-configure-flag=mutt=--enable-compressed --no-substitutes
<wingo>not in guix build --help
<futurile>wingo: help guix build transformations or I have post you can skim:
<wingo>ACTION salutes
<wingo>--help-transform i see
<wingo>this is great!
<dthompson>I *still* haven't used those cli transforms
<wingo>futurile: thanks again!! funnily enough gdb stopped crashing at -O0 but i got it to crash with a better BT at -O1
<futurile>cool - they're pretty nice if you just want to do something quickly to test
<mekeor>wingo: nice to see you hanging around here and using guix recently. i'm curious, what are you using it for? :)
<wingo>i have used guix for the last 10 years at least :) guixsd on laptop and workstation, i do my work on top
<ngz>erikeah: I have a few comments about your patch. You need to explain why tests are disabled, and why configure phase is removed. Besides, setting PREFIX is usually not needed; if it is, you need to comment about it. The description should not start with an article (here "A"). You could explain why two licences are needed. Is the project dual-licensed? Or does one of the licenses apply only to a part of the project? Nitpick: I suggest
<ngz>to use "DWM" instead of "dwn" and use G-expressions.
<ngz>erikeah: Also (nitpick): "River window manager" instead of "river window manager".
<ngz>(likewise for "River Wayland compositor"). Also the description should consist of a complete sentence.
<wingo>can you run guix shell as a shebang line for a script? i know there are line and arg-count limitations but istr nix-shell can do this
<erikeah>ngz: Thanks for feedback. I'm not very familiar with gexps yet, could you reference any example of what should I do, apart from that I will send changes once I have them
<wingo>apparently, yes
<wingo>i did not know about env -S
<ngz>erikeah: You may have a look to bspwm package in the same "wm.scm" module. It's the #$ and #~ syntax.
<erikeah>ngz: thanks!
<ngz>erikeah: yw!
<umanwizard>Hi, is it possible to create a manifest that will cause a particular environment variable to be set when I use `guix shell` on that manifest?
<umanwizard>For example, in a particular development environment, I need to depend on clang, and I also need to set LIBCLANG_PATH=/path/to/clang/lib
<remyd1>Hi, how can we check content of a build system template, eg `cmake-build-system` ?
<apteryx>consult the guix/build/cmake-build-system.scm source
<RavenJoad>I am attempting to package tree-sitter-tlaplus, but the most recent release requires tree-sitter-cli@"0.21.0". Guix currently has 0.20.10, so I upgraded to 0.22.2, but this is still failing with "Found: tree-sitter-cli@undefined", which does not satisfy tree-sitter-cli@"0.21.0".
<RavenJoad>The weird part is, I can use tree-sitter-tlaplus 1.0.8 and tree-sitter 0.22.2 (the new one), and everything works.
<remyd1>thx apteryx !
<apteryx>you're welcome!
<apteryx>weary-traveler: not sure why you'd want the P and W in there; I've never had a need for that when debugging a package build failures
<cbaines>apteryx, by the way, I'm glad to report that the nar-herder memory issue affecting hydra-guix-129 is fixed
<cbaines>I believe it was a port related issue fixed in
<peanuts>"guix/nar-herder.git - Manage a collection of Guix nar files"
<cbaines>which also explains why it was only affecting hydra-guix-129, as that's the only machine that handles /file/ requests
<weary-traveler>apteryx: i don't know if adding P and W make the environment closer to the one in which guix builds derivations (or if it makes the environment more different). i am not sufficiently familiar with guix internals to figure out the answer
<weary-traveler>you'd mentioned that guix shell -CD gives something that approximates the guix build environment. i was wondering if that approximation could be improved or if that's the best that can be hoped for at present
<remyd1>Hi, i have a "no such file or directory" issue for `chdir` here:
<peanuts>"debian Pastezone"
<remyd1>this was "working" here:
<peanuts>"Debian paste error"
<remyd1>what do I miss ?
<futurile>umanwizard: (setenv "TEST" "1234") at the top of the manifest works for me when I use it with guix shell --manifest=something.scm
<umanwizard>futurile: But I need to set it to the path of one of the packages in the manifest
<mekeor>so, i wrote this package, communinfo, that provides an equally named variable to be used like (setopt Info-url-alist communinfo). Info-url-alist will be introduced by emacs version 30. do you think that communinfo should also backport the Info-url-alist feature to versions prior 30 so that people can already use it?
<mekeor>oh no, this is #guix, not #emacs. sorry!
<lispmacs[work]>same thing, basically...?
<lispmacs[work]>isn't Emacs the default desktop for Guix?
<mekeor>there's at least one core member who uses vim and not emacs :)
<janneke>there are more core members who took a long time to convert to emacs ;)
<janneke>ACTION used vi* for some ten years before switching
<podiki>at least you saw the light... :)
<janneke>took me three summers
<janneke>but i saw a friend using emacs, yeah..
<stikonas>there is always "M-x vip-mode"
<janneke>using vi* is more declarative, which was a very nice fit for my mind
<janneke>yeah, i used evil at the time
<ieure>Even I once defaulted to nvi. But I've been all-in on Emacs for about 26 years now.
<ieure>Most devastating insult I've got these days is: "I've got dotfiles older than you."
<janneke>26 years sounds about right :)
<janneke>ACTION prolly switched summer 97 or 98
<ieure>vc-mode was the killer feature for me. Git didn't exist, neither did Org Mode. Eventually had my email in vm.
<janneke>the hardest was all my custom macros, for compilation, grep, latex, but otoh, emacs had most of that builtin
<ieure>I never had any kind of vi setup, just used it like it was out of the box.
<ieure>And it was nvi, not vim.
<janneke>had to write a lilypond mode, tho
<tschilp>Hi guix! I just added ~(gnu services mail)~ and ~(service opensmtpd-service-type (opensmtpd-configuration))~ to my system configuration to get basic system mail. The default configuration seems to expect ~/etc/aliases~, which does not exist on my system -- will I have to add this manually, or is there something I oversee (adding my user to some group or similar). So far I see ~~/Mail~ in my homefolder, but nothing under ~/var/mail~.
<mekeor>tschilp? are still here?
<janneke>mekeor: nope, they already quit
<mekeor>i send them a memo with /msg MemoServ send tschilp ...
<hapster>I have downloaded and built the guix repo locally and I am now trying to build a package. Is it correct to enter a pure shell using `guix shell -D guix --pure` and only then executing `guix build $PACKAGE`?
<hapster>I ran into a strange situation yesterday where I was first able to build a package (until I ran into errors, that is), and then later running into the issue that none of the dependencies could be found
<Guest96>I hope 5 lines is not too many:
<Guest96>scheme@(guix-user)> ,use(gnu services configuration)
<Guest96>scheme@(guix-user)> ,use(guix gexp)
<Guest96>scheme@(guix-user)> (define-configuration myconf (myfield (string "fixed") "no doc" empty-serializer))
<Guest96>scheme@(guix-user)> (lower-object (mixed-text-file "fname" (serialize-configuration (myconf) myconf-fields)))
<Guest96>$1 = #<procedure 7f00d1513f40 at guix/gexp.scm:286:2 (state)>
<Guest96>The above is a minimal reproduction of my problem. I want to see what my configuration serializes to
<Guest96>I thought lower-object was supposed to return a store item?
<juanpablo>hi im trying to add bluetooth to my services with (service bluetooth-service-type) but can't seem to make it work because i'm lacking dbus-service. Tried (dbus-service #:services (list bluez-alsa)) and (service dbus-root-service-type), but neither seem bound.
<Guest96>i.e. I'm confused why $1 does not give a string or the path to a store item
<jaft>Guest96: might give some help with what you're trying to accomplish? I'm not too familiar with this area but I do notice the end of the section right before "Exploring <derivation>" in that link mentions that ~lower-object~ is a monadic value that doesn't mean anything (yet) until run in the context of a store (hence it being a procedure, I'd assume).
<jaft>I used ~with-store~ in my home config. to grab the files of a package so, if you use the module ~(guix store)~ and run ~(with-store store (run-with-store store (lower-object (mixed-text-file "fname" (serialize-configuration (myconf) myconf-fields)))))~, you may get something closer to what you want (still seems a record is returned, in the example in the link, but the path is, at least, readable)?
<jaft>Well, I get a derivation, which is not quite what you're looking for, I think; sorry I can't be more helpful, here.
<Guest96>No problem. Good to know that lower-object probably doesn't do what I think it does
<RavenJoad>Guest96: If you use "guix repl" and import those same modules, does the ",build" REPL meta-command not work for you?
<Guest96>I get "Unknown meta command: build"
<Guest96>this is from a "guix repl", not a "guile" invocation