IRC channel logs
2023-01-12.log
back to list of logs
<fiesh>Euler-Maskerony: thanks, I guess that's the (somewhat cumbersome) way to go then <fiesh>I suppose nm-applet hast some special black magic that nmcli / nmtui don't have?! <fiesh>no worries, thanks for your help <akirakyle>anyone know what package I need for a guix shell with objdump? <fiesh>ok it turns out nmtui already works now as a user... not sure what changed since this didn't use to be the case for me. but anyhow \o/ :) <gnucode>hey guix! I got guix deploy to work. does running guix deploy update the server's guix? aka if you use guix deploy, do you still need to log into the server to run "guix pull" ? <gnucode>I suppose, you would only need log into the remote server, run "guix pull" occassionally. And then only if you wanted to log into the remote server to run "guix system reconfigure config.scm". <gnucode>It is super cool, to be able to build the "deployment image locally" and then send it to the remote server. hats off to the team that developed and is maintaining guix deploy! <lechner>gnucode / yeah, i love 'deploy' also <apteryx>gnucode: you do not need 'guix pull' unless you want to use a recent guix by a user on that machine <apteryx>the system profile gets updated from the guix you ran 'guix deploy' from <apteryx>librebooted or not, video performance is bad on that laptop (I have one). I haven't tried that old, unmaitained patch <apteryx>could be interesting to see some benchmark if you manage to rebase it <oriansj>apteryx: well the performance on Debian is good enough to watch 1080p video without lags <oriansj>but on guix, is struggling to keep up with the 720p video it previously played without issue on Debian <iyzsong>i think disable cpu mitigations may help, and mpeg format require less cpu than h264 <lfam>Contemporary video codecs are going to be a stretch on the x200 <Euler-Maskerony>Hello. I am trying to install packages on my fresh installed system, but profile builder tells that there is no disk space left, but I have not installed any useful packages, only basic ones. <oriansj>iyzsong: it plays h264, h265 and hevc just fine on Debian <oriansj>Euler-Maskerony: how big is your disk? <Euler-Maskerony>60G root and 100G home, but du tells that there is 20G of files inside root <oriansj>Euler-Maskerony: that is more than plenty for a complete system; and df -h shows no free space? <lfam>oriansj: What kernel version is used on your Debian that plays video well? <oriansj>Euler-Maskerony: and guix package -i $package doesn't work? <oriansj>Euler-Maskerony: can we get the full error message please? <Euler-Maskerony>Wait a second, please. Somehow I can read log with vim, but cat can't print it for me in readable format... <iyzsong>Euler-Maskerony: the link is broken for me <gnucode>apteryx: thanks. That's what I had guessed in my head, but couldn't quite formulate into words. <dirtcastle>but tramp can't find the ls binary path properly. so find file doesn't show anything. this was discussed in mailing lists but it didn't look like they came up solution that works <iyzsong>Euler-Maskerony: /gnu/store is mounted read-only, only guix-daemon mount it read-write <kimjetwav>Euler-Maskerony: Aside from guix, why can't a device have more than one mount point? <kimjetwav>Euler-Maskerony: It's perfectly licit and makes sense to do so. <Euler-Maskerony>Then this is not the reason why 'guix package -i' tells that there is no disk space... <zamfofex>Euler-Maskerony: I’ll note that you should be able to decompress the logs with ‘gunzip < /…-profile.drv.gz > log.txt’ <kimjetwav>In any case, iyzsong is correct, the store needs to be read-only to guarantee the validity of the packages it contains, so the guix daemon just remounts it ro, and has a private namespace where only it can write. <Euler-Maskerony>I manually created ~/.local/share/fonts directroy and populated it with my fonts. After this I ran fc-cache to update fonts. Is it appropriate? Maybe somehow it broke my system? <dirtcastle>how to chsh in guix. I need to change shell but it says pam authentication failure even when run with sudo <dirtcastle>guix home's home-zsh-service-type didn't help too. <unmatched-paren>dirtcastle: you should configure your terminal to run the right shell <dirtcastle>unmatched-paren: I used the user account config to use zsh rn. for now I have a config with that if I system reconfigure the term-console can't start. what should I do. <bumble[m]><unwox> "bumble深く傷を: add this line to..." <- thank you that does work! <dirtcastle>when I add (shell (file-append zsh "/bin/zsh/")) and reconfigure and try to boot it gets into a loop and doesn't login. I installed zsh4humans and pk10 before this. but I deleted all zsh related file like history,env, profile,rc. it still doesn't work <bumble[m]>I'm a new sway user (using guix) would anyone here familiar with sway recommend swaybar, polybar or waybar? Which of these should a new user use? <bumble[m]>ok thanks will start there. thanks for sharing the config files as well <dirtcastle>my problem was solved. I gave zsh as shell on system config and bash as my shell on home config. now both use zsh <oriansj>dirtcastle: guix only puts files on disk; it doesn't change the reality of the software and configurations you specify. <jpoiret>dirtcastle: depends on how you login <davidl>Anyone who knows how to setup HSP/HFP for a bluetooth headset on Guix? I added a custom default.pa profile for pulseaudio, which makes the profiles show up in pavucontrol, but when I select them I get an error saying these profiles are still unavailable. Im guessing it is due to not having an ofono service running (I have built the ofono 2.0 package locally), but Im not sure whether it would be enough to have ofonod running, or if I need to <davidl>compile pulseaudio with ofono compile option flag or similar. <jpoiret>davidl: if i were you i'd try with pipewire instead <jpoiret>not that pulseaudio couldn't be made to work but it's probably easier to use <jpoiret>you may have to also compile pipewire with ofono support <dirtcastle>oriansj: .zshrc normally in any distro should run on login. I understand guix is very different that's why I'm asking here. <dirtcastle>jpoiret: I use the official 1.4 qemu image. it uses slim. <dirtcastle>I login normally? and then I login through sshing into qemu. but zshrc doesn't run on either. <ecbrown>dirtcastle: i don't know what your full issue is but what about .zprofile <jpoiret>Oh, when sshing i'm not sure zshrc is sourced <jpoiret>At least i know the behaviour is weird there <ecbrown>zshrc it is not sourced on ssh but only for logins or some such combination <ecbrown>ACTION went back to bash and never missed zsh <apteryx>oriansj: is debian using the intel-vaapi-driver-g45-h264 patch? <apteryx>ecbrown: that's because on guix bash is built with -DSSH_SOURCE_BASHRC <jlicht>oriansj: I was never able to get the driver to work on 'modern' kernels, sadly. I only use my T400 as a server now anyway :) <apteryx>ecbrown: and/or -DNON_INTERACTIVE_LOGIN_SHELLS <dirtcastle>ecbrown: it is not sourced on login. anyway the system config has disabled a lots of services to keep it simple for a vm image. so even if I have password for my user I still don't have to input it to login. <dirtcastle>ecbrown: my issue is when I login into my vm, open terminal the zshrc is not already sourced. <apteryx>I have some questions regarding the design of cross vs regular builder definition in Guix build systems <apteryx>it seems the former exists only to massage inputs in the different input bins? <apteryx>e.g., a native build system has only 'inputs', while a cross build systems has both 'native-inputs' and 'inputs' <civodul>apteryx: yes, and also the cross builder typically introduces additional implicit dependencies <apteryx>it seems having native-inputs and inputs in *both* cases would help fixing bugs like #25235 <apteryx>civodul: the addition of standard-cross-packages occurs in the lower procedure though, not cross-gnu-build, for example <apteryx>so it seems that if we were to let the inputs sorted into their explicit categories even for the native builder, we could unify both the cross and native builders and fix bugs like the one mentioned above? <ekaitz>hi! did I understand correctly that if I install ntfs-3g system-wide (in the config.scm) my system will be able to mount NTFS directly? <apteryx>ekaitz: it should work this way, yes <ekaitz>I mean, no need to configure anything else like services or so, right? <ekaitz>apteryx: yay thank you very much! I've been mounting stuff manually for 3 years -> yes, i'm like that <apteryx>mount has a mechanism to look for helpers on PATH to mount things <ekaitz>oh but it doesn't find it if you have it in your profile? <civodul>apteryx: i'm not sure i understand the proposal, but yes, there may be room for improvement <ekaitz>it doesn't, and the docs say you have to install it globally <apteryx>ekaitz: what command did you run exactly? <ekaitz>apteryx: trying to use the mount from nautilus fails <apteryx>civodul: it's not much of a proposal but some idea: keep the host inputs as "inputs", the native-inputs as "native-inputs" in all situations (cross or native), then when we wrap things with inputs, we do not get the undesirable native-inputs mixed in as is curretnly the case for native builds <ekaitz>anyway, i'm reconfiguring with the thing globally installed, if it works like this i'll consider this solved <civodul>apteryx: oh got it; but then there are two things: how things appear in the bag, and how they appear in build phases (#:native-inputs vs. #:inputs) <civodul>in build phases, #:native-inputs only appear when cross-compiling <civodul>changing it would be "pretty hard" (euphemism) <apteryx>do you mean because of the incompatibility introduced (with package definitions?) <civodul>exactly, we'd have to review build systems and most packages by hand, checking for #:native-inputs/#:inputs assumptions <oriansj>apteryx: well something has to be giving Debian the signficant performance advantage when playing video on the exact same hardware <apteryx>right. we'd need to spend a good amount of time on scripts helping with automating that <civodul>maybe we could see if there are easily recognizable patterns <apteryx>but other than those hard difficulties, the idea seems to have merit? and unifying build systems would be a thing then, right? <oriansj>jlicht: well would the proper guix solution be to specify an older kernel then? <apteryx>e.g, reduce gnu-build and cross-gnu-build into just gnu-build <civodul>apteryx: merging them would introduce quite a bunch of conditionals <apteryx>with the additional cross inputs added as part of lower, as is currently the case <civodul>it's not a clear win, nor a worthy goal IMO; there's little code duplicated anyway <civodul>i guess the first step would be reviewing packages to estimate the feasibility of all this <apteryx>I'm experimenting unlocking cross-pyproject-build, so I'll try out some ideas there to feel things <apteryx>we could migrate one build system at a time (pyproject has few packages using it yet) <civodul>speaking of big changes, it looks like antioxydant is gathering dust <civodul>which is a bummer because Rust packaging as it is is a threat to the stability of the whole shebang <apteryx>agreed, it's an important piece of work <ekaitz>apteryx: it works only when the package is installed globally (just tried), there must be something with the package discovery <apteryx>strange -- I'm sure I've wrested with this before <apteryx>the group should be the same whether the package is installed in the system or user profile, I think <mirai>apteryx: I mean, for a nonroot user to use fuse <mirai>maybe it needs to belong to some specific group? <apteryx>lrwxrwxrwx 1 root root 73 Dec 31 1969 /run/current-system/profile/bin/ntfs-3g -> /gnu/store/9wwqsp1a9xx3qjnhbnnzadrcjcp07a11-ntfs-3g-2022.10.3/bin/ntfs-3g <ekaitz>i'm not sure but the docs specify it <apteryx>mount will look for mount.ntfs-3g on path, I think <ekaitz>the documentation of it is under udisks-service <mirai>By weakly, I mean put a requirement on service X only if its present among the services list <apteryx>my geiser still hangs returning the prompt *sometimes*. am I alone? <apteryx>when it starts it seems I can't recover until a reboot <jlicht>oriansj: Sure, I guess. IWBN if the fabled Someone is able to fix this to work with more recent kernels though :) <bjc>mirai: no, it doesn't. shepherd's dependency resolution is very rigid <mirai>hmmm.... That's rather unfortunate. <bjc>it is. i've been looking at adding some flexibility to it, but the code is also fairly rigid <bjc>don't get me wrong: given its assumptions, it's actually quite nice <bjc>too bad about the assumptions, though ;) <jlicht>if you generate a shepherd service from a (Guix) system service, you can generate the list of dependencies dynamically <apteryx>civodul: was the bag->derivation vs bag->cross-derivation distinction made as an optimization? <jlicht>It will just be static after a 'guix system build config.scm', obviously <bjc>jlicht: depends on context. for instance, i need to do some funky stuff before the ‘file-systems’ service is finished. there's no decent way to do that which i can see <bjc>(why yes, i *am* back on my zfs nonsense) <apteryx>otherwise it seems using bag->cross-derivation for all derivations should work, albeit with adjustments for the buiders/package definitions (it's a superset of the former) <mirai>I was wondering if it could have been implicit <jlicht>bjc: Oh snap, I don't think there's a generic way to do that currently. Something like After/Before targets from systemd would make that easier <mirai>rather than having to explicitly type something of the sort: (service connman-service-type #:wants iwd-service-type) <bjc>mirai: after a cursory skimming, i think we want the same thing. ie: the ability for a service to inject itself into the dependencies for another service <bjc>jlicht: exactly what i'm thinking <civodul>apteryx: bag->cross-derivation does more work and is tailored for the job <bjc>i wasn't going to go down the systemd path of “start order is orthoganal to dependency order”, though. it makes everything vastly more complicated and i have no idea why it's useful <bjc>but adding a ‘needed-by’ field to shepherd services, which is just a reverse-dependency, should be fine. but even that requires more surgery than i'd hoped <oriansj>jlicht: well we either use what we have and work around the problem or actually just fix the problem ourselves directly. But I am not the person for fixing graphics drivers but if there was a bug bounty, I'd be willing to throw some money at it <oriansj>I'd even donate hardware if it means someone else with those skills is motivated to solve my problem <mirai>bjc: I didn't write it under this mail, but I was thinking about the various systemd [Unit] directives <mirai> RequireMountFor, Wants, Depends, Before, After, etc. <bjc>yeah, i saw your bug report a bit ago. it's nice to know we're all on the same page <bjc>i'm really only interested in dependency injection for the time being, though. systemd is really way too complex for my liking. it has like 6(‽) different ways of declaring dependencies, not counting their inverses. it's insane <mirai>I wonder if theorem provers could be used in Guix <oriansj>mirai: well you could make guile act like prolog if you really wanted <mirai>could be a nice help for dependencies, cycles, etc. <bjc>somewhere around there. i'd have to go back and count <bjc>(i'm also not counting before/after) <bjc>i'm sure there's *some* reason so many exist. but i doubt i'd have come to the same conclusions =) <nckx>I found the man page (I forgot the cute naming convention: ’systemd.unit’). <bjc>i kind of like the way systemd names its files, tbh. i find it easy to remember and sensible <nckx>Oh wow: Requisite, BindsTo, PartOf, Upholds, it's a veritable thesaurusfest. I want to say these were introduced later, but maybe I'm wrong. <nckx>bjc: Sure, it's cute, not bad. <mirai>bjc: I think it also had the negations (NotBefore, NotAfter, ...) <nckx>I'll always be grateful to systemd for (amongst other things) separating needs from ordering, but I agree the above keywords are at *best* impossible to remember… <mirai>nckx: needs implies an ordering, no? <bjc>the separation of start ordering from dependencies makes sense to me in, like, a ‘Wants’ context, but not in a bunch of others. i think it was a mistake to declare them “orthogonal” and walk away <mirai>I can't think of an example where it isn't <bjc>there's weak dependencies, like ‘Wants’ where the goal is to try and bring something up as part of, say, graphical login, but it's not important that it be started by then <bjc>i think a lot of systemd makes sense when you ignore pottering saying it's not about desktop users ;) <mirai>I think systemd service files are vastly better than the soup of shell scripts before <florhizome[m]><panosalevro> "are there any people interested..." <- I Tried hugo ... <bjc>yeah, systemd gets a bad rap, but it did do some things pretty well <mirai>peak cargo culting times when someone wanted to write a simple service <mirai>the timers aren't too bad of an idea too <mirai>it's a bit clunky that it can only operate on services (so you need to write a service file to call your program) but it has good ideas in it <mirai>and it also is DST aware (people that expect for cron to be DST aware are in for a surprise) <florhizome[m]><nckx> "If you don't get a help message,..." <- OK and then? <florhizome[m]>I think i had all the dependencies at that Point but it still didnt build and Go Error Messages are pretty mystical <unmatched-paren>florhizome[m]: guix passes the verbose flag to go build by default (not sure why, it doesn't provide much helpful information) <florhizome[m]>all around maybe we need inprovements in the Go Importer and build system first <florhizome[m]>There might be some Problems Like simply Not having the right versions of dependencies <pret7>heya people! I'm having a strange issue where I can't run modify-inputs in the REPL <panosalevro>florhizome[m]: ok thanks. it's the most popular static site builder, it's a shame we don't have it in guix <pret7>im trying to run this command, "(modify-inputs (package-inputs node-lts) ((delete "llhttp bootstrap")) <pret7>and I get this error: unknown file:6:0: source expression failed to match any pattern in form (modify-inputs (package-inputs node-lts) ((delete "llhttp bootstrap"))) <mirai>I'm somewhat surprised there isn't a asciidoc parser in clisp/scheme <pret7>for some reason I was eliding all the docs cause I expected it to be the same as modify-phases <mirai>ah of course, multiple X-Debbugs-CC don't work, it only accepted the last one <florhizome[m]>panosalevro Like i said i think it would be helpful for such Projects to improve our Go tooling First. You might be able to run the prebuilt binary or package it Outside of guix official repo <pret7>o also, how do I use a module correctly when I'm working on a channel in the repl? <pret7>so I have a channel im working on and I open up a file in emacs <pret7>then start geiser and C-c C-a <pret7>but then I don't have like guile builtins and stuff <nckx>florhizome[m]: I know, but you quoted very little of my message and I don't know where you are now. <nckx>You didn't even say if the binary is damaged or not. <pret7>like %load-path is not bound and stuff like that <nckx>ACTION has to step away from the computing machine. <unmatched-paren>pret7: i don't really understand how you'd work on a channel from the REPL <pret7>uhh what I've been doing is opening the file im working on in emacs, then C-x C-e to eval things as I write them <davidl>jpoiret: Ok, thanks for the tip. <pret7>but my lack of understanding of modules is causing issues <pret7>like I'm not sure why load-path and stuff are undefined if I change to the module I define in my channel <panosalevro>i asked the developer of zrythm and said the reason that he stopped updating the guix package is that it's taking months for his patches to be accepted. does anyone know anything about that? <bjc>%load-path should always be defined, i think, although it may not be what you want <bjc>but, minimally, it should have the guile built-in stuff <pret7>ice-9/boot-9.scm:1685:16: In procedure raise-exception: <pret7>error: %load-path: unbound variable <bjc>maybe something in your ~/.guile? or in your geiser config in emacs? <pret7>no worries, I'll read up on guile modules, I'm sure im doing something daft <panosalevro>florhizome[m]: why does it take too long? because the patches need to be evalueted according to the FSDG? <bjc>there's a lack of people able to do the work <pret7>possibly maybe geiser is setting the module imports wierd <pret7>only thing in my .guile is readline <bjc>the actual committers in guix are a pretty small crew, unfortunately, so a lot of patches just languish. i wish i had some kind of solution <pret7>Oh! I do run guile with `guix shell guile guix -- guile $@` <pret7>as I recall I did that cause I was having issues with guix modules <mirai>^^ this would be immensely faster if REUSE spec / SPDX identifiers were used <mirai>my guess is that there's not that many maintainers, not enough time and patches being buried by other patches as time passes <bjc>pret7: i would think that a load-path is still defined from the guix shell invocation, though <pret7>its defined the moment the repl comes up <bjc>same, and it's reasonable <bjc>if i ‘,m (gnu)’ i still have %load-path defined <bjc>maybe it's something in your module? <pret7>hmmmmm yea i see the same thing <pret7>weird, maybe its cause my module isnt initially in the load path or something <florhizome[m]>nckx: 'guix shell --no-grafts -D Gnome-Shell --pure -- msgfmt --help fails at building the info-dir derivation <Fare>Hi. I'm having trouble trying to install on aa64, wherein tracker 3.3.3 fails dbus tests. How do I determine which packages I am trying to install that depend on it? <pret7>also when I try and run anything with replace in modify-phases <pret7>i get this: unknown file:24:21: replace: 'replace' may only be used within 'modify-inputs' in form (replace ... <pret7>(ive been working around the module issue by running code in some (gnu packages ...) module that's similar ish <florhizome[m]>so i ran 'guix gc --contents=verify,repair' as you recommended <florhizome[m]>nckx: when i just Run /gnu/Store/...gettext-0.21/bin/msgfmt --help I get an Error about libtextstyle.so.0 File too short <pret7>I think this is because replace gets pulled in from (guix utils)? and there it specifies that it *must* be in (modify-inputs <pret7>ok i just hadn't imported (guix build utils) <mirai>anyone familiar with how connman works? <mirai>does it provide any way to indicate network connectivity or "startup finished" ? <pret7>also is there a way to get build logs as something is building <nckx>florhizome[m]: OK, I recommended running ‘sudo guix gc --verify=contents,repair’. Did you? If that doesn't fix it, it means that there's no substitute available. It *should* download a shiny new gettext package to replace your broken one, but I'm not sure if it does fall back to building (it should) or if grafts can confuse it. <nckx>Really, both of the latter ones would be report-worthy bugs IMO. <nckx>ACTION AFK again, sorry. <apteryx>bcdefs.h:51:10: fatal error: readline/readline.h: No such file or directory <apteryx>repro: guix build bc --target=aarch64-linux-gnu <apteryx>ACTION takes at peek at what poky does in the yocto project <rekado>bc has a patch bc-fix-cross-compilation.patch <apteryx>"These rules are not cross-friendly so delete them and we'll generate the file offline." <apteryx>I'll try refreshing our patch from nix first <apteryx>the patch we have is already the most current <Fare>how can I override tracker-3.3.0 to build despite some failed tests? <Kabouik>I'm installing packages within the R statistical software using the guix.install() command by Rekado, which supposedly just eases the work to import the R package from CRAN into a Guix package and install it with guix install under the hood. <Kabouik>And I am getting this issue (https://0x0.st/o7WN.txt) when trying to install an R packag even though `jq` is indeed installed in my Guix system and I do have `jq.h` in its `/gnu/store/.../include/`. Any ideas? <Kabouik>(Got to go but I will check answers later, if any. Sorry!) <bjc>remove it from %desktop-services (or don't add it in the first place, if you're not using %desktop-services) <bjc>there's also a shepherd service that runs it, iirc, but i can't remember what it's called <the_tubular>Can't even read what my config without my whole server crashing ... <the_tubular>So I'd like to stop it manually before I mess with my config <bjc>i think ‘herd stop xorg-server’ should do the trick, but don't quote me on that <the_tubular>Seems to have worked, i'll report if it fixes the crash <mirai>it will take your system down <mirai>(not completely, but it won't be consistent) <mirai>whatever starts gdm for you also starts elogind and friends <mirai>you stop gdm, you also stop those as well <apteryx>seems the issue is that fbc (built by bc) should always target the build machine but is curently targetting the target and can't run at build time <Fare>ok, even removing desktop-services and xorg for now, the installation fails because linux-modules.scm says it wants ahci, but there's no such thing on this aa64 platform, it seems. <apteryx>hmm, bc built fine without the patch <apteryx>ah, better (after reconfiguring my system without any binfmt stuff): /gnu/store/4y5m9lb8k3qkb1y9m02sw9w9a6hacd16-bash-minimal-5.1.8/bin/bash: line 1: ./fbc: cannot execute binary file: Exec format error <acrow>Can I field any questions concerning the patches provided for issues 60537 or 60612? <apteryx>back to: bcdefs.h:51:10: fatal error: readline/readline.h: No such file or directory with the nix patch. I'll try fixing it <apteryx>is $(CC) not defined in Automake when cross-compiling? <apteryx>it's never defined I think, intended to be used by the user? <apteryx>ah no, autoconf will set it if AC_PROG_CC is used <graywolf>Hello :) How can I get list of channels in the scheme code? I want to pick a different kernel based on if specific channel is available or not. <apteryx>but CC from the environment is honored <nckx>graywolf: (guix describe)'s current-channels. <graywolf>nckx: That indeed seems to be what I need, thank you very much. <Fare>what's the simplest way to hotpatch a package (tracker 3.3.3) so it will skip a few unit test checks? <nckx>I guess that would be --without-tests=tracker from the CLI, assuming that applies to your situation. Otherwise, (define tracker/untested (package (inherit tracker) (arguments (substitute-keyword-arguments (package-arguments tracker) ((#:tests? _ #f) #f))))) in code. <nckx>That code is untested in more ways than one. <tremon>hi all, what determines which files end up in which output? if I simply define (outputs '("out" "debug" "lib" "static")), many files end up in lib/ and debug/ without me having to do anything. is there a specification somewhere about common outputs and how they're supposed to be used? <mirai>I think you're supposed to select which files you want in each of the outputs <mirai>take a look at git or libavif <tremon>yes, that's what I thought too. so I expected a number of empty directories (which didn't happen, the build errored out because the output directory "static" didn't exist) <tremon>but I was surprised to find many files already in lib/ and debug/ <nckx>tremon: Both are on purpose. Guix doesn't create output directories by default so that people notice the noisy error when an assumption breaks. But then build system authors decided to save people time & effort and have some variables set to other outputs if they exist, or to automatically install things like LICENCE files to each output if found. Both well-meaning, but they conflict. <tremon>I'm not complaining, just asking for pointers to the documentation or code <nckx>I meant to explain that this is not one coherent documented behaviour or code snippet, just the interaction of various unrelated parts. <tremon>I've tried to wade through the build-system code before, but I just get lost very quickly <nckx>Yeah, it's a bit confusing at first. <nckx>Most of the stuff that actually runs at build time is in guix/build/foo-build-system.scm, not the other one. <nckx>You'll find the default phases there. <nckx>There is no well-written guide to this. <tremon>thanks, knowing to look in guix/build rather than guix/build-system/ already helps a lot :) <mirai>tremon: grep will be your friend <mirai>(or jungle guide if you prefer) <ieugen>hi, I'm managing infrastructure for a company and I am looking at nix and guix to setup developer environment. <ieugen>Is there a new version available in some other place? We use some ansible collections that require a new version of ansible. <ieugen>What is the procedure to update ansible? <mirai>you open issues by sending mail to bugs-guix@gnu.org <bjc>if you want it updated, you're probably going to have to do that work yoursel and submit a patch <antipode>leugen: "./pre-inst-env guix refresh -u ansible" (though it doesn't work for all packages yet) followed by committing & sending to guix-patches@gnu.org. <antipode>The process is documented in the manual, though I don't know if all of it is documented. <mirai>I'm afraid it might not be as straightforward as a simple refresh <antipode>python packages should be straightforward to simply refresh <antipode>There's a 'ansible-core' dependency though, so you'll have to update that too. <mirai>depends on how entangled the dependencies can get no? <mirai>my point was that refresh can be either trivial or much more involved <antipode>Looking at the package definition, the dependencies don't appear entangled at all (except for the single versioned python-resolvelib-0.5, don't know why another version is chosen, its uncommented). <antipode>(And there are quite some phases replaced, which might break or become incomplete after updating) <florhizome[m]><nckx> "florhizome: OK, I recommended..." <- I solved it by running a full guix gc, then guix pull & guix Update Afterwards. I found a thread on Reddit where a User Had the same Problem <nckx>Awesome. That did a bit more work than strictly necessary (than --verify=contents,repair) would have done, but I'm glad it helped. <florhizome[m]>Next problem: how do i specify hibernation to a swapfile on an encrypted partition <nckx>However: please run gc with above option, really, it will check all files and try to repair what it can. <nckx>florhizome[m]: I know someone has that working but it's not me. <florhizome[m]>nckx actually that didnt do it although it replaced gettext a few times <nckx>Maybe that was partition. <nckx>florhizome[m]: OK, good (but pity) to know; that's probably the graft bugginess I mentioned. Thanks for the correction. <jackhill>no, I've only tried it with swap as an LVM lv inside LUKS, not a file. However, I would assume that if you have swapfile hibernating, the LUKS part wouldn't change what needs to be done <florhizome[m]>Archwiki gives this hint 'the resume parameter must point to the unlocked/mapped device that contains the file system with the swap file.' <ieugen>I could not find any guix for MacOS, except a mailing list discussion 5 years ago. <ieugen>Some devs use MacOS (don't ask me why :) ) . <Fare>considering the amount of conditional compilation all over the place for Nix on macOS, it would require a lot of work to get Guix to work there, and most importantly—-buy in from the core team, which I don't imagine would be easy to get. <Fare>(but I think it would be a great idea) <rekado>Kabouik: the problem here is that the importer doesn’t realize that jq needs to be present in the build environment. <rekado>what you have installed elsewhere in your profile does not affect the build environment. That’s by design. <rekado>Kabouik: done with commit 2a2b494370e9602ba291e38b8b42e1794e2a77bf <apteryx>some progress on bc cross-compilation: fatal error: libmath.h: No such file or directory <apteryx>isn't libmath supposed to be provided by gcc itself? <abhicherath[m]1>Is there any way to see build logs as something is building? I get anxious looking at the spinner lol. <akirakyle>Anyone know what's up with cuirass? Looks like all the aarch64 workers are sitting idle but my guess is that all the pending builds are for aarch64 <civodul>fishy: the cuirass worker on overdrive1.guix is being told there's nothing to build <apteryx>oh... success with cross-compiled bc, I think <apteryx>does someone know where to email patches to GNU bc? <apteryx>they don't seem to have a mailing list <nckx>civodul: How did you list those? I had to restart the PPC64 cuirass-workers last week, but I don't know why this regularly happens. <civodul>nckx: i check /var/log/cuirass-remote-worker.log <civodul>i didn't take the time to check the other side tho <nckx>I was looking for a shepherd subcommand, I'm a spoilt brat. <rekado>something’s not right: reconfiguring my aarch64 machine I’m made to build qemu-minimal 7.2.0, but that build says it’s not supported on aarch64-linux <apteryx>and you are not even cross-compiling? <rekado>but the build fails earlier already <rekado>(I tried building qemu directly on a different machine later) <rekado>first thing that fails is the ominously named /gnu/store/lgs88lmj6y1rri1s7549rjs3gdxadykh-openbios-qemu-ppc-1.1.drv <rekado>I’m building natively on an aarch64 machine <rekado>I need this for qemu-minimal, which I need for grub-efi <vagrantc>there was a thread on guix-devel that maybe touches on qemu uninstallability on aarch64 due to splitting out some components <sneek>vagrantc, you have 1 message! <sneek>vagrantc, acrow says: that acrow has some more code for you <rekado>ACTION should probably subscribe to guix-devel again, but dreads the overflowing inbox <rekado>vagrantc: thanks, I’ll browse guix-devel the <civodul>abhicherath[m]1: there's no way to do that right now <civodul>it wasn't clear it'd be this popular ;-) <abhicherath[m]1>Any short guide on messing with the commands? (If not I can just read the code no problem) <abhicherath[m]1>But also, any workarounds for now then? I'd really appreciate not having to leave the repl, is there a (build-in-store) function that takes args or something <vagrantc>rekado: maybe i'm misremembering, i cannot find the thread now ... thought it had to do with unbundling ipxe <rekado>there’s one about ipxe, but this is a different (but similar) problem <rekado>I’ll send a new mail to guix-devel <ekaitz>hi! what's the recommended line width for the dog/guix.texi <mirai>depends on the content though, some @commands can't be split over multiple lines <mirai>in that case, leave them as is <ekaitz>oh, I've put 75 and my code block looked like thicker than others :S <ekaitz>maybe this was changed in the past <ekaitz>if anyone is interested in Zig, I sent a patch series to guix-devel with a tentative zig-build-system <apteryx>rekado: why not filter your inbox? all the mailing lists messages go to their own directory, so my INBOX stays manageable <apteryx>I can share my small filters if that's useful (for Gnus, but must be easily adapted) <rekado>tschilptschilp23: oh, so only a part of the documentation files are actually installed? <tremon>when was the syntax for substitute-keyword-arguments changed, and was it intentional? <tremon>(substitute-keyword-arguments _ ((#:phases phases) #~(modify-phases .... etc now gets happily ignored by guix, doesn't even give a warning, the modification is just ignored <tremon>cargo-culting my way through the source, it seems I need ((#:phases phases '%standard-phases) now, but I don't understand why <akirakyle>My git-blame led me to the couple of commits that unbundle ipxe on which there was that thread on guix-devel <akirakyle>That's as far as I got in debugging this since it's currently blocking me from doing a guix system reconfigure on my machine