<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!
<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.
<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.
<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
<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
<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.
<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>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
<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.
<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>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
<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.
<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!)
<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?
<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
<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
<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.
<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.