IRC channel logs


back to list of logs

<bdju>ah the base-services page in the manual has it as an example
<bdju>okay I'm in a bit of scheme trouble again. I think there was a conflict with how my services section was laid out and the new bit
<bdju>pasting in a moment
<bdju>so the modify-services part is the new part
<leoprikler>paste the (remove ... %desktop-services) into the %desktop-services of your modify-services expression
<leoprikler>i.e. (modify-services (remove ... %desktop-services) (udev-... ...))
<leoprikler>then line up the brackets
<jlicht>I regret replying to people on the weird ML thread. How can I get people to stop CC'ing me without spamming the place up even further?
<leoprikler>weird ML thread?
<jlicht>well, weird in the sense that it was getting a bit off-topic for guix-devel at least :-)
<bdju>I've messed up my parens and such and am having a horrible time now
<leoprikler>it happens to the best of us ;)
<bdju>I keep jumping between "invalid field specifier" and "missing closing parenthesis" but it says the last line of the file
<bdju>I'll just paste my whole config and maybe you or someone can find the mistake(s), my blind guessing has failed me
<bdju>oh I forgot the error
<jlicht>bdju: these are the cases in which some lisp-aware autoformatting feature has saved me many times, as often the indentation tells you where the problem is
<bdju>currently it's "/etc/config.scm:111:1: missing closing parenthesis"
<bdju>jlicht: someone told me something like that before but I'm editing in emacs this time and the parens are colored and such. I'm not sure what else to do
<jlicht>your services seems to extend to the name-service-switch and setuid-programs fields
<leoprikler>try this:
<leoprikler>oh, and you should delete the single %desktop-services
<bdju>the one on its own line?
<bdju>well, the one without parens next to it I should say
<leoprikler>the one on its own line
<bdju>so I copied over the modified services section and got "/etc/config.scm:92:18: error: source expression failed to match any pattern"
<bdju>then deleted what you said and now get "guix system: error: source expression failed to match any pattern"
<leoprikler>without a line?
<leoprikler>try (define %stripped-desktop-services (remove ... %desktop-services))
<leoprikler>outside the operating-system
<leoprikler>then (modify-services %stripped-desktop-services (udev-...))
<bdju>same error
<bdju> config + error
<bdju>not sure if I did it right, this is a bit confusing
<leoprikler>ahh, you're missing a pair of brackets around "udev-configuration ..."
<leoprikler>also you should probably declare %stripped-desktop-services before the OS
<bdju> getting something about an unbound variable now
<bdju>made those changes
<leoprikler>drag the closing bracket after udev-configuration to the 7 others
<bdju>ahh okay
<bdju>new error is asking if I forgot a use-module for android, which I actually did I guess
<bdju>no error so far this time!
<bdju>okay, off to a TTY to test
<bdju>still no luck... same thing saying to check my udev rules...
<bdju>not sure if it's worth a reboot or if something is still not perfect in my system config
<leoprikler>you may try restarting udev first
<bdju>oh, that is a good idea
<jlicht>fwiw, I had this (rootless-android stuff) working some weeks ago :-)
<bdju>no luck so far, but how should I be restarting udev?
<cornburglar>How do I get audio working? my config has %desktop-services but I suppose that does not contain the necessary bits and I'm not exactly sure what my config needs to support audio output
<leoprikler>bdju: "sudo herd restart udev"?
<leoprikler>cornburglar: you don't really need extra services for audio
<cornburglar>Well it seems it's muted then
<leoprikler>are you running GNOME or something else?
<cornburglar>Idk how to unmute w/o alsamixer
<bdju>well restarting udev was more dramatic than expected and killed my session
<cornburglar>I'm using cwm
<bdju>BUT, it now works!
<cornburglar>so not a DE
<bdju>thank so much for the help leoprikler
<leoprikler>cornburglar: can you open pacmd in a command line?
<cornburglar>commmand not found
<leoprikler>then you need the pulseaudio package
<cornburglar>and if I add pa to an ad-hoc environment then I am told that PA daemon isn't running, and won't be able to start PA because I don't have dbus running either
<cornburglar>(why I think extra configuration is needed)
<leoprikler>isn't dbus-service-type already loaded by %desktop-services though?
<leoprikler>fwiw, there is a documented alsa-service-type
***jje_ is now known as jje
<roptat>hi Guix!
<civodul>Hello Guix!
<raghavgururajan>Hello Guix!
<civodul>hey, raghavgururajan
<jlicht>hey guix!
<kmicu>Thank you civodul for perf improvements! ヽ(*＾▽＾)／
<raghavgururajan>civodul o/
<MaliRemorker>Who is guix?
<MaliRemorker>I've never seen that person
<leoprikler>They're a weird fellow
<jlicht>s/guix/y'all/ would also work ;-)
<kmicu>guix = guix community = all
<sirmacik1>Hey Guix!
<kmicu>( ^_^)／
<sirmacik1>Just a week of vacation and I missed the biggest shitstorm on mailinglists (;
<civodul>kmicu: there's still a lot more to do, but i was already please by the result!
<civodul>esp. since these were simple changes
<MaliRemorker>sirmacik1 I wish I have missed everything, starting with that medium article
<MaliRemorker>suddenly GNU seems small and vulnerable
<sirmacik1>Since the matter is not technical, it's not surprising to me. that's not really GNU's area of expertise
<civodul>i wanted to get rid of the openblas replacement but i wonder if that can go to 'staging'
<civodul>it has more dependents than what we usually allow for 'staging', but many/most seem to be R packages
<mbakke>civodul: you mean like this?
<civodul>mbakke: exactly, thank you! :-)
<civodul>what branch is it?
<mbakke>'staging', which is well underway:
<mbakke>actually, that page fails to return...probably a good sign :P
<civodul>surely :-)
<civodul>oh the change above is on 'staging' indeed
<civodul>silly me
<civodul>mbakke: the last evaluation failed (2737c7f)
<mbakke>civodul: I saw that now, any idea why?
*civodul looks
<civodul>i'll hack that cuirass thing one of these days...
<mbakke>the only change in that evaluation is an innocuous mesa patch
<mbakke>heh... I've been dreaming of that too ;-)
<civodul>i almost started doing it the other day
<civodul>i don't like that
*civodul tries a new evaluation
<civodul>in other news, offloading seems to be buggy for me now
<civodul>like 'guix offload' disconnects in the middle of a build
<civodul>does anyone else experience that?
<lprndn>Hello guix!
<mbakke>civodul: I'm a heavy offloading user and can't say I've experienced that.
<mbakke>I haven't restarted my main system in a month or two, though.
<civodul>yeah, i think it's very recent
<civodul>either the core-updates merge or the libssh upgrade
<civodul>hi lprndn!
<civodul>oooh got it
<civodul>we're setting a 10s timeout in (guix scripts offload)
<civodul>and with libssh 0.9.0, that timeout is actually honored
<civodul>so if the build process remains silent for 10s, we disconnect
*shrdlu68 is loving guix so far
<civodul>shrdlu68: thanks for the good vibes :-)
<lprndn>In (gnu system linux-container), does container-script actually start services defined in the os's definition?
<civodul>yes, it's the script returned by "guix system container"
<lprndn>civodul: cool, thanks! Reading the procedure, I was just not able to find where it was happening.
<lprndn>Is it the same for the packages declared in the system-packages?
<civodul>lprndn: what do you mean by "the same"?
<civodul>the script is not a package
<lprndn>civodul: Packages declared in the system-packages are also part of the os started with the script? I'm asking but, really, I don't doubt it is. haha
<civodul>lprndn: ah sure yes, if you have an OS with a bunch of packages listed in the 'packages' field, they'll show up in the container
<civodul>if they don't, that's a serious issue :-)
<jlicht>civodul: wow, the speed at which you go from "stuff be broken" to a hypothesis and possible fix is very impressive.
<jlicht>regarding the offloading timeout
<civodul>jlicht: well i really needed it and i was a bit guilty anyway ;-)
<civodul>mbakke: new staging evaluation:
<civodul>so i'm not sure what that compiler backtrace was about
<civodul>we haven't seen anything like that in some time AFAIK
<fps>hmm, guix build --check --rounds=4 some_package doesn't seem to do 4 rounds
<roptat>fps, maybe it's grafting 4 times?
<roptat>try with --no-grafts
<fps>roptat: nope. it's also a local package which i add to to guix by way of GUIX_PACKAGE_PATH
<roptat>I think with check, --rounds is simply ignored
<fps>if i use it without check then it just tells me the hash of the installed package
<roptat>check is for rebuilding a package you already have, rounds is for building a package multiple times when you don't have it yet
<fps>yeah i want to do a couple of rounds on a package i already have
<roptat>right, rounds works only when you don't have built the package yet
<roptat>I guess we could change that though
<ixtlan>So.. I'm attempting to customize my sortofworking guix system. Package manager recommended me to set my GUIX_PROFILE, but the commands suggested only sets it temporarily. That does not seem to make sense. I looked up where it's set, in .guix-pro../etc/profile, but it's kinda.. root-only, and even root can only read, not write. Normally I take that kind of thing to mean 'you should not mess with this'. On the other hand stuff in i3 seems to fail because it
<ixtlan>can't find dmenu which is searched as /run/currentsystem/etc.. the 'default' path set by the system. Presumably it'd work if I changed the profile file. Just checking though: Is there another place I should set that kind of thing, and is the 'profile' in fact system-generated from this?
<roptat>fps, if you didn't install the package in any profile, you can run "guix gc -D `guix build foo`" to remove foo, then you can run "guix build foo --rounds=4" if you want
<fps>roptat: ah ok..
<roptat>ixtlan, I'm not an i3 user, I'm sure there are some here though, but I can suggest sourcing your .guix-profile/etc/profile from your .bash_profile, or setting your PATH in your i3 configuration maybe
<roptat>but I'm pretty sure guix does that already, maybe you only need to reboot for new environment variables to take effect everywhere?
<ixtlan>i3 is where I can see something fail - I am worrying that probably i3 isn't the only thing that would fail, given that the guix package manager is also taking notice. So I see it as a general, system problem?
<ixtlan>I thought, am thinking, also, that .guix-profile/etc/profile is run automatically.
<ixtlan>However, as far as I know, environment variables are not preserved at shutdown. At least for all other systems I know of, they're set anew at startup, often from .profile files.
<fps>.bash_profile is only used when run interactively i think
<roptat>.guix-profile/etc/profile is generated automatically by guix and it should be loaded at startup
<roptat>I'm not completely sure *how* though
<ixtlan>Oho :]
<roptat>maybe from /etc/profile
<roptat>but when the DM is started, it loads root's environment, not yours I think
<roptat>so you'll have to configure i3 to load your own environment when it starts, probably
<ixtlan>... /etc/profile could work as a template, but not on a per-user basis.. is .guix-profile/etc/profile generated anew in perpetuity or is it just at new installs?
<fps>a xsession manager should source the relevant files though
<roptat>display manager
<shrdlu68>Is there a letsencrypt service type?
<roptat>.guix-profile/etc/profile is part of the current generation of your profile, it's generated whenever you create a new generation of the profile (when you make a transaction with guix package, guix upgrade, guix install or guix remove)
<roptat>shrdlu68, there is!
<shrdlu68>roptat: Sweet!
<ixtlan>Erh, so.. a reset of the profile whenever a new package is installed? I can't customize my environment then.
<roptat>right, usually it takes a reboot if there's any new environment variable
<ixtlan>I'm fine with reboots, I just need a place to specify the variable :]
<roptat>they point to .guix-profile/... though, so for instance $PATH doesn't has to change every time you install something
<roptat>doesn't .guix-profile/etc/profile already has all you need?
<ixtlan>No, since GUIX_PROFILE points to /run/system/something where it should in fact point to /home/<me>/.guix-profile. And it's set in .guix-profile/etc/profile
<ixtlan>Alternatively I could adjust it later on if some file is automatically sourced.. in my home dir, a .profile perhaps?
<leoprikler> /home/<me>/.guix-profile should be a symlink ot /run/system/something
<roptat>it's a symlink to /var/guix/profiles/per-user/<me>/guix-profile
<roptat>a .profile would work I guess
<ixtlan>As it's a symlink.. the root ownership makes sense. And I'm thinking that I could copy that file, use that locally and from it first source the system profile, then overwrite the GUIX_PROFILE variable.
<roptat>I've never had to change any of these on the guix system though...
<ixtlan>Well.. I'd like to know what your GUIX_PROFILE is then, and how it was set for you?
<ixtlan>Erh. And also which command you use to do a shutdown in the nice way. I've been using the power button. So if there's anything triggering a preservation of environment variables, they could have been inadvertently circumvented that way.
<roptat>ixtlan, I'm not on the guix system right now
<ixtlan>Fair :)
<roptat>mh... no I use the power button
<roptat>looking at my config, it seems I don't load anything special
<roptat>I don't think GUIX_PROFILE is set on my system
<roptat>but I don't use a desktop environment
<roptat>so maybe that's it: I only need these environment variables when I open a terminal
<ixtlan>Hm :]
<roptat>(and my config is generated by guix, including my menu, so it refers directly to store items)
<ixtlan>Silly me and my graphical leanings :>
<roptat>(I don't even need $PATH :p)
<roptat>it's a graphical environment, just not a full DE
<ixtlan>Wait. You have no desktop environment, but you do have a menu?
<ixtlan>Well. Similar for i3. That, too, is not a DE.
<roptat>well, if you can make it load your .guix-profile/etc/profile, you'll have solved your issues I think
<roptat>so maybe through .profile as you said
<ixtlan>I shall try! (dramatic music ensues)
<civodul>fps: --check always does a single round, for some reason
<civodul>i agree that it's kinda confusing
<civodul>in "normal" mode (no --check), --rounds does work as expected
<ixtlan>Back. I tried something else in the end - and it turns out dmenu was not installed. Installing it -did- help matters.. there's still other things though. It's like i3 was not properly installed somehow.
<ixtlan>Is there any system definition around for 'base minimal system' that I can then extend on after reconfiguring to it?
<fps>civodul: --rounds is also not doing anything when the package is already built
<fps>btw: how long can one expect a guix system vm-image to run at the least?
<civodul>fps: when the package is already built, it's expected that --rounds does nothing
<civodul>it's really only for when you're building something for the first time
<truby>I'm having a bit of trouble with the linker wrapper when building something with clang, it seems to be passing the linker flags as strings which then get interpreted as libraries with that name to link against. E.g. its looking for a library file called because "-pic" is being passed as a string. Any ideas?
<shrdlu68>How can I append entries to ~/.bashrc via skeletons?
<shrdlu68>Can I petition for a colored $PS1 in guix?
<shrdlu68>/etc/bash//bashrc in Gentoo has some code to only enable it for terminals that support it.
<MaliRemorker>VNC service before $PS1 please :-P
<MaliRemorker>I contributed the server, now all we need is someone who knows how to write services to help me do it
<shrdlu68>I'll do it myself if I can get some pointers on how to go about it.
<MaliRemorker>maybe a separate "trivial" package to get the coloured PS?
<roptat>shrdlu68, you're looking for default-skeletons in (gnu system shadow)
<civodul>shrdlu68: i wouldn't suggest petitioning :-), but you could propose a patch on guix-devel for discussion
<civodul>sounds like a good idea to me
<shrdlu68>roptat: I'm not sure it's okay to completely overwrite the default ~/.bashrc
<shrdlu68>etc-service-type also sounds like a good idea but I'm not sure how to append to a file.
<roptat>I don't think it's possible
<shrdlu68>civodul: Just a plain email with the proposition?
<shrdlu68>I've found a "submitting patches" guide:, so I'll be doing that later.
<civodul>shrdlu68: yes, and perhaps with a patch to make things more concrete
<civodul>in this case, sending to guix-devel is preferable IMO, because we're really calling for discussion
<civodul>such a patch is easily reviewed :-), but we want to hear what people think
<shrdlu68>civodul: Alright, thanks.
<leoprikler>talking about shells, why does zsh not load site-functions from the system profile by default?
<jlicht>I am trying to package something which runs the generated `./configure` script as part of the script, but this script still has a `/bin/sh` reference by default. What would be the nicest way to deal with this?
<jlicht>so configure is generated with /bin/sh and immediately executed :/
<roptat>jlicht, use substitute* in a phase before bootstrap?
<jlicht>but there is nothing to substitute
<jlicht>or at least, that is what grep tells me ;-)
<wingo>weird :)
<roptat>ah, you mean bootstrap generates a configure script that contains /bin/sh, and then calls it?
<roptat>then you can patch the call to configure out
<jlicht>roptat: yes, that is a much better way to describe my issue :P
<bdju>looks like the Kakoune editor is a release behind
<jlicht>I am working on packaging, but there is a big mean warning about some licensing issues in serving binaries of it with openssl < 3.0.0 due to an incompatibility. Would it suffice for me to mark this package as non-substitutable, or are there bigger issues here?
<leoprikler>my reading of this is, that you can build the source against earlier versions, but not distribute binaries produced through such builds
<leoprikler>that would translate to "no substitutes if openssl < 3.0.0"
<leoprikler>Offloading would probably be an issue too
<nckx>jlicht: ‘substitutable?’ only disables client requests, not distribution (i.e. ‘guix publish’ doesn't care), so it's not an option.
<utraz>everytime i reboot my computer and do a guix operation i get the following message:
<utraz>guile: warning: failed to install locale
<utraz>hint: Consider installing the `glibc-utf8-locales' or `glibc-locales' package
<utraz>and defining `GUIX_LOCPATH', along these lines:
<utraz> guix package -i glibc-utf8-locales
<utraz> export GUIX_LOCPATH="$HOME/.guix-profile/lib/locale"
<utraz>See the "Application Setup" section in the manual, for more info.
<utraz>When i install glibc-locales and export GUIX_LOCPATH it goes away, but comes back when rebooting
<mbakke>utraz: the daemon also needs GUIX_LOCPATH; you can edit '/etc/systemd/system/guix-daemon.service' to point it to your user profile (instead of root's)
<utraz>i should've clarified i'm using guix system!
<pinoaffe>when I try to install this package I get an error ERROR: In procedure primitive-load: In procedure scm_lreadr: /gnu/store/7x3ydg9yld0jc0vymkf378gm3z2pa292-i3-gnome-3.34.0-guile-builder:1:10239: Unknown # object: #\<
<pinoaffe>what does this mean?
<ixtlan>ultraz: That sounds similar to my thing with GUIX_LOCALE, even if I am now convinced the i3 install is where the fault is in my case. I didn't try to fix the locale issue yet.
<nckx>pinoaffe: A syntax error in your builder. For starters, (list → `(
<utraz>would never have guessed
<nckx>pinoaffe: Where did you even get (list? It's very different from `( or '(.
<ixtlan>Ack. GUIX_PROFILE, that is. Silly fingers.
<pinoaffe>utraz: I had a similar issue, don't think it's caused by i3 since it also happened on tty, but I also run i3
<ixtlan>Anyway, it should be possible to solve it by using one of the profile files that sets up your system and/or terminal, but I don't know if it's the 'right' way to solve it.
<pinoaffe>it got fixed after I made a new system generation replacing en_GB.utf8 with en_US.utf8 in my config
<pinoaffe>nckx: thanks, no clue where I got that, might've made it up myself
<nckx>pinoaffe: Happy to help! Was hoping there wasn't some misguided tutorial/example somewhere out there.
<pinoaffe>I tend to write from memory or copy from preexisting packages, in case of doubt I'll take a look at or the docs
<nckx>pinoaffe: Just so y'know, url-fetch … /archive/ … will have to be changed to git-fetch if you want to submit this to Guix, because those tarballs aren't stable.
<pinoaffe>I know
<fps>oh, it would be nice to be able to write out a manifest if in an environment (e.g. an --ad-hoc one)
<nckx>fps: It would ;-)
<dongcarl>mbakke: I'm sorry I've not been responsive this weekend I've been sick, taking a look at your email now :-)
<fps>nckx: or even better a somewhat slick workflow that enables creating, activating, manipulating and saving manifests
<fps>kind of like conda environments or whatever the new hype in python-town is called..
<dongcarl>fps: I believe rekado had a nice GIF demo doing that in a jupyter notebook..
<mbakke>dongcarl: no worries, thanks! :-)
<fps>dongcarl: GIF? like in the graphics format?
<nckx> ?
<dongcarl>mbakke: I do apologize for rushing the patch last time, I will do better next time. I'm actually struggling with a problem right now that only you can answer... My technique of picking out `mingw` paths from non-CROSS_ env vars and putting them in CROSS_ variants seems to have been broken by the core-updates merge...
<mbakke>ouch :/
<mbakke>dongcarl: how can I reproduce the issue?
<dongcarl>mbakke: Well, I'm rather embarrassed to admit, but just `guix build nsis-x86_64` will trigger it
*dongcarl face is a tomato right now
<mbakke>dongcarl: heh :-)
*mbakke checks it out
<mbakke>it's OK, we all make mistakes :-)
<dongcarl>For some clarity, I used to do it to "CPLUS_INCLUDE_PATH" "LIBRARY_PATH" "C_INCLUDE_PATH", and I've tried switching to just "CPATH" and "LIBRARY_PATH", but that triggers the `include_next` `stdlib.h` problem
*dongcarl is thankful for understanding
<mbakke>dongcarl: are you getting the #include_next problem during the build of nsis?
*mbakke builds mingw toolchain, which will take a little while
<dongcarl>mbakke: let me check. will come back with facts
<dongcarl>mbakke: With the current commits in `master`, `nsis` fails at the `fix-env` stage, because I expect "CPLUS_INCLUDE_PATH" and "C_INCLUDE_PATH" to be set, but we only set "CPATH" now
<dongcarl>If I change "CPLUS_INCLUDE_PATH" and "C_INCLUDE_PATH" to just "CPATH" in the `fix-env` stage, then I get:
<dongcarl>/gnu/store/bl2h77rzm0gcpkxhhqsccym06359ydhh-gcc-cross-i686-w64-mingw32-7.4.0/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or directory
<mbakke>dongcarl: try to add (setenv "C_INCLUDE_PATH" (string-append (assoc-ref inputs "libc") "/include"))
<dongcarl>mbakke: this is after I change "CPLUS_INCLUDE_PATH" and "C_INCLUDE_PATH" to just "CPATH" in the `fix-env` stage?
<mbakke>dongcarl: indeed
*dongcarl trying
<dongcarl>mbakke: No luck :-( The problem seems to come from an invocation of `x86_64-w64-mingw32-g++`, so perhaps the `CROSS_` env vars are the ones that need tinkering?
*dongcarl gathers log
<mbakke>right, also CROSS_CPLUS_INCLUDE_PATH in that case
<mbakke>@ build-succeeded /gnu/store/0s1d0k88wn1wg0gqw22a84n8mqvpgbac-gcc-cross-x86_64-w64-mingw32-7.4.0.drv -
<mbakke>hmm, why is CROSS_CPATH not set already?
<dongcarl>mbakke: oh, should it be?
<dongcarl>I think this is probably a weird package that tests the limits of Guix
<dongcarl>Since it uses both a native and a cross compiler in the same build
<dongcarl>mbakke: Here are the logs:
<dongcarl>Here is the patch
*dongcarl reads thru 30756 for the 99th time
*mbakke has to go
<mbakke>dongcarl: i will look into it further tomorrow, ping me if you are around
<dongcarl>mbakke: That sounds good. Thank you!
*dongcarl is grateful
<efraim>does anyone have sddm working with a wayland display? I couldn't get it to launch enlightenment-wayland, not sure if it was e or sddm
<nckx>Is ci.guix slow (~100k/s) for everyone?
<mbakke>dongcarl: so the reason CROSS_LIBRARY_PATH etc are unset, is because Guix does not understand that it is cross-compiling.
<dongcarl>mbakke: That makes sense
<mbakke>not sure how to do the equivalent of `guix build --target=` from Guile..
<mbakke>Perhaps we can access cross-gcc search paths?
<dongcarl>mbakke: I do want to say that the commits we have the in the tree worked perfectly pre-"core-updates merge"
<mbakke>I expected as much :-)
<mbakke>I gtg again and tend visitors, just wanted to share my sudden insight.
<dongcarl>for sure, thank you!