<lilyp>iskarian: regarding zig, there's a line "const default_cc_exe = .*" in src/libc_installation.zig <lilyp>we could use that to patch in our own default (e.g. gcc) <iskarian>I don't think it should be getting to that fallback detection at all, though <iskarian>I'm just not sure what exactly changed to caused that <lilyp>tbf i don't fully understand it either <lilyp>but it appears variations of that code have existed longer <iskarian>We should make the CC substitution anyway <lilyp>hmm, that could work but the patch for that would be a slightly more complicated one <iskarian>replacing "cc" -> "gcc" in default_cc_exe would be complicated? <lilyp>no "cc" -> store path for gcc or clang would be easy <lilyp>using "CC" unconditionally on the other hand would be a more complicated patch, as zig may weasel around it <iskarian>Ah, I would have just done "cc" -> (cc-for-target) since zig doesn't have a dependency on gcc:out already AFAIK <lilyp>cc-for-target is wrong here, you need an installed cc <lilyp>i.e. a cc that can run on target rather than produce code for target <iskarian>Huh. Well I definitely misunderstood cc-for-target. <lilyp>cc-for-target gives you the correct native-input cc to produce target code :) <ytc>hello. is there anybody here who is using gnu guix on a thinkpad x200 or other librebootable computers? <iskarian>Hmm. I think clang makes a "cc" symlink. Should gcc do the same? <lilyp>we usually don't use -toolchain packages, but IIRC both do? <lilyp>okay, I was mistaken, that's probably a clang-internal choice <iskarian>It seems reasonable for the -toolchain packages to do it IMO <lilyp>Not sure it does, it ironically breaks with cc-for-target <CaptainDrewBoy>Hi! I ended up going with the guided install (didn't use it bc at first it wasn't working). I installed i3 and it automatically grabed the st terminal. I don't mind this at all. But how do I apply patches to the st that guix installed? I know that guix sd doesn't take kindly to make install, so installing it separately is a no-go (I imagine). <podiki[m]>CaptainDrewBoy: I don't know st, but take a look at "package transformations" in the manual <podiki[m]>you can add patches to be used when building <podiki[m]>otherwise, perhaps taking the package definition and making your own version <geex3>i would think most st users apply patches so it should be easy. but i don't think it is <geex3>I need to define a simple (openvpn client) service that runs "openvpn /etc/openvpn/client.conf" command instead of having the client configuration in the configuration.scm - (some of the other services depend on the virtual network to be in place to listen on that interface, so nm-applet is not ideal, and the vpn config may change between guix system reconfigures) <geex3>lets make openvpn-client-service easier <raghavgururajan>geex3: I don't think its a good idea, as the advantage of guix is declarative+reprducible system management. <geex3>well currently users need to run 'sudo openvpn client.conf' <geex3>for now i will stick with 'sudo nmcli connection import type openvpn file /path/to/file' but looking for way to have it at the herd level with a conf file -- will share if i end up having any luck <singpolyma>Hello everyone :) On today's adventure, I run: ./pre-inst-env guix lint <my-new-package> from inside guix environment guix and am told: ls: cannot access '/usr/local/var/guix/daemon-socket/socket': No such file or directory <singpolyma>Any ideas what I should do? Is there a ./configure switch I need or something? <iskarian>singpolyma, yes, you must do `./configure --localstatedir=/var' <singpolyma>I'm also getting a lot of ;;; In procedure load-thunk-from-memory: incompatible bytecode version <iskarian>I think the documentation could be made clearer, because I ran into the same issue when I was just starting <iskarian>Assuming that you've updated the checkout since you first ran `make', you probably need to re-bootstrap/configure/make <iskarian>Typically just `make' is fine but if weird things start happening, it's time to start over <singpolyma>so I need to ./bootstrap again? I re-ran ./configure and then make just now to add the switch you suggested, but maybe need to bootstrap again too? <iskarian>Yeah, because I think bootstrap embeds the path to whatever Guile you have in your environment <iskarian>(it's that Guile version difference that causes "incompatible bytecode version") <singpolyma>hmm, did ./bootstrap && ./configure --localstatedir=/var/ && make -- no change still getting the warning <singpolyma>it does seem to be working though, just printing a lot <singpolyma>yeah... I'm afraid of how long that rebuild will take though :P <apteryx>singpolyma: 'rm guile' from your tree <apteryx>I have no idea what that guile binary is used for, but this comes up every now and then <singpolyma>When I submit a patch-series for new packages, should it always be one commit per package, even if there are say two very closely related ones (like a package and a helper package only it depends on) ? <iskarian>Better to err on the side of one-commit-per-patckage <iskarian>Hmmm. What cross-toolchain is the most likely to actually have substitutes available... <apteryx>you cuold try 'guix weather' to check, perhaps? <iskarian>"guix weather: error: target=aarch64-linux-gnu: unrecognized option" :( <sneek>Welcome back g_bor, you have 1 message! <rekado>the ARM boards I ordered in May will be delayed until at least mid-October. <PurpleSym>rekado: Do you know what the status of wip-haskell is? I don’t see any commits since July. <rekado>PurpleSym: I have not been following any work on wip-haskell. I only created it and applied the first patch. <PurpleSym>Hm, okay. I’ll take a look at the GHC 8.10 patches. Do we follow Stackage or just import packages from Hackage? <nckx>iskarian: --system, not --target (not sure what the latter would mean, don't think it would make sense). <nckx>(Hm, I guess using both --system and --target *would* be unambiguous, but in any case it's not implemented :) <efraim>the cmake packages FTBFS intermittently on aarch64 on core-updates-frozen. Part of me wants to change the 'check phase to (or (assoc-ref %standard-phases 'check) (apply (assoc-ref %standard-phases 'check) #:parallel-tests? #f)) since that always seems to take care of it <guerrilla>So, question: How do I list what packages are installed in the base system? guix package -I as root doesn't list anything. I looked through the 'guix system' man and didn't see anything relevant there either. <nckx>I guess I'd use something like ‘guix size $(realpath /run/current-system)’, guerrilla. <nckx>Aside, note that root is just another user, not ‘the system’. That matters or you'll encounter misexpectations. <guerrilla>nckx: Thanks. Yeah, I suspected the latter, just was the best I could think of for a first try :) <nckx>It's not a great answer but I don't know if there's a way to get a more package-oriented output. <wigust>guerrilla guix package --profile=/run/current-system/profile --list-installed <guerrilla>nckx: Well it did list the packages at least :) <guerrilla>wigust: ahhh *this* is what I want. Thank you <nckx>wigust: Awesome. I'm going to add that to my list :) <nckx>It's just not a use case I've ever had. What do you use it for? <nckx>Well, that's the catch with the above command, it uses the (correct but strict) Guix definition of ‘installed’ and won't list any packages that are used only by services but not added to your system profile. elogind is there (presumably) to provide loginctl, but e.g. xorg-server isn't. <nckx>Several people (me included) have managed to Guix-package systemd at various levels of quality over the years. It shouldn't be too hard to finally package it for real and extract udev from it. <nckx>For relative values of too. <nckx>It won't be a tea party. <sneek>I think I remember glv in #guix 11 months ago, saying: nckx: OK.. <jpoiret>alright, I've managed to get wayland gdm -> sway, now i'll clean up everything, add some configuration in the docs and it should be good to go <jpoiret>also, fixing this convinced me that people should stop using gdm if they're not also using gnome <dstolfa>jpoiret: yeah, i use gnome so i quite like gdm's integration with it, but it's a horrible piece of software honestly <jpoiret>yeah and reading/debugging it is horrible <jpoiret>switching to a wayland session wasn't too hard, but the wayland mutter always crashed <jpoiret>solution was adding XCURSOR_PATH to its env variables since it couldn't find its cursors in the usual dirs <Soheil[m]>How can I turn on the keyboard backlight on Guix System? <nckx>Soheil[m]: The low-level answer is ‘cat /sys/class/leds/$NAME/max_brightness > /sys/class/leds/$NAME/brightness’ (as root). <nckx>If you use upower, I think it has a dbussy interface to the same thing, but that's beyond my ken. <nckx>And on some laptops (like Thinkpads) it's handled by the kernel/ACPI/vendor driver like thinkpad_acpi. <nckx>Even then the /sys interface still works, though, and always should. <nckx>jpoiret: That's horrible. ***jonsger1 is now known as jonsger
<jpoiret>i can't seem to find anything about copyright in the 'Contributing' part of the manual: is it mandatory for any patch? <dstolfa>jpoiret: it isn't, but you can add it <dstolfa>entirely up to you. i usually forget :P <cafkafk>I feel like i saw it mentioned somewhere in some document <cafkafk>Pretty sure I was just thinking of M-x guix-copyright or something thou disregard me ***jonsger1 is now known as jonsger
<jpoiret>Should documentation be provided in the same commit that introduced some changes? <guerrilla>I wonder if many GoboLinux users will migrate to Guix :) <nckx>Did something happen there? <guerrilla>No, I was just thinking that their raison d'etre is organizing programs by version number and guix goes above and beyond that ***vidak is now known as mobian__
***mobian__ is now known as vidak
<nckx>guerrilla: Ah. I don't know; good question. That's also about all I know about GoboLinux too… <guerrilla>It's the main thing they advertise on their site (which is kind of pretty by the way) <nckx>Nix/Guix's use of directories is just a low-overhead way to implement higher-level functional package management. Does Gobo do that? <nckx>I'd love to try it but if not, I'd just be left sitting there thinking ‘OK, now what?’. *nckx .oO seems not (/System/Index etc.) <dstolfa>AFAIK gobo is just automating management of what *nix users would normally think of as /opt, that is to say just managing a bunch of program versions and probably setting up the path <dstolfa>i don't think it does much of what guix does <dstolfa>e.g. you can probably mutate configs as much as you want and so on <guerrilla>I see it as between traditional distros and Guix/Nix <nckx>OK, that was exactly my interpretation too :) But of course I'm wearing my bottle-thick Guix glasses. <nckx>depending on your allegiance. <raghavgururajan>Are we gonna do staging --> master merge before core-updates-frozen --> master merge? <jpoiret>alright, wayland GDM works 100% now (and is faster than X11 GDM), i'll send the patch later <jpoiret>currently trying to make GDM -> Sway work with setting up the environment (we don't have Xsession or xinitrc for wayland) <jpoiret>for now i've changed the Exec=sway desktop entry to Exec=/bin/sh -l -c sway but i don't think this should be the proper solution <nckx>I hesitate to ask how ‘DM speed’ is even a thing… <jpoiret>it boots up faster on my system which is nice. It was more noticeable on the vm, testing with X11 GDM took ages to boot up <jpoiret>(alas it still needs to start the whole gnome-shell so it is not instantaneous either) <nckx>I don't think editing sway.desktop is the way to go or even necessary, since it sounds like a GDM problem. <nckx>So it's not loading your environment? <nckx>About a year ago I reluctantly knew exactly whose job it was to load which environment file, but my brain seems to aggressively GC stuff I wish I hadn't learnt. <jpoiret>GDM doesn't load anything when starting wayland sessions <jpoiret>tbh once guix home is more stable we'll just design our own DM which starts given profiles with their env, seems like the cleanest solution to me <jpoiret>is using hardcoded /bin/sh a good idea for scripts? <jpoiret>i'll just patch GDM source to run the session through a set custom script <jpoiret>but no actually i'll just use $SHELL <maximed>If it is part of a package, it is preferred in Guix to ‘absolutise’ the /bin/sh to /gnu/store/.../bin/sh, because the behaviour of 'sh' can change <jpoiret>maximed it'll be a script akin to xinitrc <maximed>(though in practice, it doesn't seem to change much) <jpoiret>does that mean i need to add sh as an input? <maximed>possibly 'patch-shebang' will take care of patching the shebang <maximed>(I'm not familiar with xinitrc --- is it a configuration file to be modified by the user? If so, maybe keep it /bin/sh, such that the configuration file doesn't become invalid after a "guix gc") <jpoiret>i'll put the script inside the scheme code so i'll put the right shebang manually <jpoiret>it's the code responsible for setting up the environment for an X session <jpoiret>i'll just look at how xinitrc is handled ***jonsger1 is now known as jonsger
<mfg>Hi guix! I have clang-toolchain in my profile but stddef.h cannot be found. Is this in a special output? i can see it in the store belonging to clang. <nckx>mfg: Works fine here. Are you sure you're build system/environment is sane? And no, it's not in a separate output. <maximed>mfg: what is the value of $C_INCLUDE_PATH? <maximed>If it is undefined, maybe clang-toolchain and gcc-toolchain weren't in your profile previously, so C_INCLUDE_PATH is unset, so you need to restart to have these environment variables defined <mfg>nckx, maximed: Ah, running clang from the command line works. I'm using emacs wich clangd so i guess there is a difference leading to that "error" <permcu>Hi everyone, is there a way to add local files/ folders to the operating-system definition so that they are added on system creation? I would like to use this to create a ready to run vm image. <iskarian>nckx, I thought cross-compiled packages were different <kraai>I'm trying to package elm-test. Its package-lock.json specifies acorn 7.4.1, but Guix includes 8.4.1. I think this is causing my build failure. How should I resolve this? <nckx>They are, iskarian. But they're not built by any of the Guix build farms. <nckx>But you're right; they could be. <nckx>kraai: Package 7.4.1 if you think the odds are great enough to justify the effort. With some luck you can inherit from 8.4.1 and simply adjust the version + source fields. <kraai>nckx: Do you mean modify package-lock.json so that it refers to 8.4.1 instead? <iskarian>nckx, (gnu ci) does have %cross-targets after all ;) <pkill9>permcu: you could create a package that uses (local-file "<path>") as it's source and put that in the (packages) declaration <iskarian>It might be useful to add cross-building %core-packages as a low-priority job... <pkill9>then they would appear in /run/current-system/profile/<path> in the VM <iskarian>I'm not sure. It just sucks that any venture into cross-building is cut short when I see I have to re-build GCC & co. <mfg>clangd expects to find clang builtin headers at "../lib/clang/<version>/include" so that's why it doesn't find stddef.h moving the binary to the extra output breaks the relative path <iskarian>mfg, Does clangd itself look for the headers? <mfg>especially "if you moved the binary around, move it back!" <iskarian>ah, I see, clangd is one of the "extra" clang tools <iskarian>I'm not familiar with clang; if there's a way you can override the dir it looks in, like "-isystem /path/to/clang/lib"? <iskarian>or maybe "-internal-isystem /path/to/clang/lib"? <iskarian>It's funny that you bring that up, recently I was looking at ways to properly split up clang, like backporting their use of GnuInstallDirs <mfg>well at least for the builtin headers i think the relative path in clangd would have to be substituted with the correct store path. The docs seem to imply that these are too essential and therefore hardcoded... Every other header (especially those in say CPLUS_INCLUDE_PATH) just work as they should <nckx>iskarian: There isn't yet a concept of ‘low priority jobs’ but it could be added by someone who needs it 😉 <nckx>kraai: I meant the opposite (actually package @7 for Guix so elm-test is happy), but both are valid. If you think elm-test is being too pedantic, it could work. Python packages do that a lot. <iskarian>mfg, perhaps, though I'd prefer a more general fix. clang takes a long time to build and has a lot of dependents, so it would probably be easier to edit what is invoking clangd to use -internal-isystem or something <iskarian>until the underlying issue is fixed, that is. <mfg>makes sense. In my case it gets invoked by emacs lsp-mode. But i'm not using the guix package - i'm using spacemacs. <geex3>can i test build and start a service from .scm file, without reconfiguring system? like ad-hoc or something? (for developing/testing new service) <mfg>So one workaround is to add the correct store path to an arbitrary clang++ invocation and use bear to generate a compile_commands.json from that. Now clangd also picks up the stddef header <mfg>but this has to be done for every project so it's working but not nice :D <muradm>any one used certbot service? when does it generates initial certificate? <muradm>should i trigger it manually first time? <muradm>does it writes logs somewhere? :) <muradm>could not find better time to start using certbot-service-type.. :) <lfam>muradm: I think it's back up <raghavgururajan>I tried `(set-font (make-instance 'xft:font :family "Noto Sans Mono" :size 10))`, but got error that its not found. <jpoiret>mhmmmm i love when my script doesn't work, only to realize that's because i've been pretending that partial applications of vararg procedures do work as usual <jpoiret>good old "functional programming" and vararg <jpoiret>alright, so wayland gdm -> sway now works and starts the WM with the right login environment (and thus guix profile) <raghavgururajan>muradm: mcron is run to renew certificates. But if you want it to manually start it for first time, execute `./var/lib/certbot/renew-certificates` <excalamus>I notice that when I ssh into my guix machine from termux that emacs shows emojis yet when I'm using emacs directly, they don't render. Any idea why? <excalamus>this is, like when reading the same erc instance <Hydragyrum>when you're SSH'd into a machine you use your local fonts <Hydragyrum>so odds are the guix machine doesn't have fonts installed/enabled that show those emojis <excalamus>looks like it might be controlled by either harfbuzz or perhaps png rendering. Whatever, I'll just disregard emotion for now :P <jpoiret>let's say I have two commits that I think should be kept separate, do I send them both in the same mail, or in successive mails? this is my first contribution <jpoiret>(i've never used debbugs before too) <jpoiret>also on a side question: is there any specific reason guix uses debbugs instead of more *ahem* modern git platforms? (gnu policy, impractical, etc...) <excalamus>I'm writing up some notes about a recent build I made. To get the needed modules, I'm curious the "right" way to find them. Some are suggested by guix build. Sometimes, the error message is vague, like "/home/ahab/test.scm:22:14: error: pypi-uri: unbound variable". I solved this by cop <excalamus>How would I go about finding the module that provides pypi-uri? <lfam>excalamus: I know it's in 'guix/build-system/python.scm' <lfam>I don't know the "Scheme way" to find that out <lfam>But trusty grep gets the job done <lfam>For Scheme-y questions you can also get good advice in the #guile channel <excalamus>good tip, thanks. I'll start hanging there, too