IRC channel logs
2026-02-01.log
back to list of logs
<gabber>is there a service that can `echo 50 > /sys/kernel/debug/asoc/rockchip,es8316-codec/dapm_pop_time` once at boot time? <dtx>I would like to run a branch of guix because a test for a depedency (python-minimal@3.9.13) of an inferior package php7 I am using is failing. Is there a guide for forking guix at a commit and just using it to provide an updated environment for an inferior? <dtx>because this is the second time I've had problems with old tests not working breaking me setting up this shell environment on a new computer (last time was a problem with Go tests). <dtx>updated meaning I'll change python.scm to skip those tests <dtx>Or do y'all know of a way to override a dependency of an inferior package more simply? <dtx>I tried doing "guix shell --without-tests=python-minimal -m manifest.scm" , but that doesn't work <dtx>it still runs the tests and still quits on that failed test <futurile-afk>dtx: build guix from source and alter the package that you're interested in I guess. <futurile-afk>dtx: you could 'normally' just use a couple of a packages in a local folder, but not with something so deep in the depenency tree I guess <futurile-afk>dtx: you could investigate using time-machine with your own set of definitions <yarl>I am adding a phase to tweak and enable compilation for aarch64 to a package that does not compile on this system yet. The package has no argument field, thus I am adding one. What is the best form/pattern? Should I as of now take into consideration potential futur modification and think about it to avoid recompilation in case of modification of flags for a specific architecture? <futurile>don't forget that you can watch the minimalistic FOSDEM devroom stream - currently Andrew Tropin talking about guile/guix development <futurile>yarl: I wouldn't worry about people adding additional arguments that much, if it's needed someone can also the package later <futurile>yarl: mostly you will see your option2 in the archive - so if you're intending to upstream it use that <yarl>futurile: Ok I'll keep it simple, thanks. <futurile>yarl: if you look in uuh maths.scm I think it is there's a lot of packages that have slightly different compliation due to architecture. There's some specific functions you can use. <futurile>oh wow they just demo'd using nvim and nrepl with ares <futurile>yeah, he does great talks, but compressed down to 25 mins is hard - I imagine it's particularly hard English is your second language <futurile>oh nice Jessica Tallon has a VSCode extension for Guile <futurile>yarl: do you need the empty list at the end of it? and check cran.scm to see if other people use 'when' - I think people use that where you don't care about the other outcomes <futurile>yarl: probably depends on who reviews it <yarl>futurile: are you sure? arguments needs something. <yarl>when actually returns nothing when the test is false. <futurile>yarl: that's why people use 'when' I think <futurile>yarl: of course I can't immediate find an example so don't worry about it heh heh <identity>`when' returns trash that you should not rely on. `when' and `uniess' are only for side-effects, not for returning values <futurile>identity: ah fair enough, thanks - must be misremembering <identity>returns trash that you should not rely on = return value unspecified <yarl>identity: doesn't when returns #<unspecified> only when test if #f? <yarl>(define-syntax-rule (when test stmt stmt* ...) (if test (begin stmt stmt* ...))) <yarl>Anyway, I don't think it's a good idea to use (arguments (when ...)), right? <identity>yarl: the last form is, for some reason, specified to be in tail context, so there is no easy way to make them return trash when the code inside the branch is ran, because expanding (when #t expr-or-stmt ...) to (if #t (begin expr-or-stmt ... *unspecified*)) is invalid, as the last expr-or-stmt is not a tail-call anymore <futurile>Simon Josefson's talk about Guix Container Images is about to start <futurile>Dave's talk on reactive functional programming was really interesting - and I'm not a web person heh heh <sunless>quassel-guy: i'm trying to install the entire toolchain including rustup using the rust installer in the "guix --emulate-fhs" container <sunless>yarl: can you help with guix shell container stuffs? <yarl>I don't know but please explain, maybe someone else can if I can't <quassel-guy>sunless: bro, I just make a manifest.scm file for each project and run it automatically using direnv in shell and emacs-envrc in emacs, https://paste.debian.net/hidden/71e9f7c4. Seems this compiles stuff properly but rust of guix upstream is at 1.85 and not 1.93 <quassel-guy>sunless: this is for my spicific project for trying to find angle of arrival of sound so i need other GUI and alsa libs <sunless>quassel-guy: i'm also using direnv and envrc but it's not working, i'll try to adjust my manifest for now, i'll tell you how it goes <quassel-guy>sunless: i can't open your pastes, it says your paste entry could not be found <quassel-guy>you have to run `eval $(direnv hook bash)' to make direnv work it seems <sunless>quassel-guy: lemme try again with the link <sunless>i think the problem is in the manifest and setup.sh (guix shell --emulate-fhs ...) <quassel-guy>and it seems you have to do `pwd >> ~/.config/guix/shell-authorized-directories`, and in envrc just put `use guix` <quassel-guy>sunless: why are you trying to do --emulate-fhs, for me just guix shell -m manifest.scm worked fine <quassel-guy>sunless: It seems thre's a branch in guix git called test-rust, they seem to have upto 1.90 <quassel-guy>but I was fine using 1.85, changed some parts of my code to work with 1.85. <quassel-guy>sunless: sorry, i was wrong, the branch is called rust-team <sunless>but the latest stable version is 1.93 <sunless>i'd rather spend more time learning about --emulate-fhs to be on the bleeding edge versions <sunless>is there anyone knows how to pass $PATH (automatically add "~/.cargo/bin") and $LD_LIBRARY_PATH (fix libgcc errors) to a "guix shell --emulate-fhs" container <sunless>oh boy, i've re-read that post multiple times yesterday ... maybe this time it'll work <sunless>untrusem-: thanks, lemme check it out <sunless>i'm a beginnner not only in guille but programming in general, that second article looked way too much for me (i've just successfully added cargo to path, now i want to "cargo run hello-world" but i'm getting libgcc errors) <sunless>current problem: "error while loading shared libraries: libgcc_s.so.1: cannot open shared object file: No such file or directory" when running "cargo run hello-world" <sunless>for some weird reason when in the container i do "export LD_LIBRARY_PATH="$LIBRARY_PATH"" it works <sunless>i can't remember the blog specifically (i remember running factorio tho) but that seem to be the solution to the gcc library errors <sunless>so i tried adding "export LD_LIBRARY_PATH="$LIBRARY_PATH"" to .envrc and --preserve="LD_LIBRARY_PATH" <sunless>when i enter the container and "env | grep -i ld" if find an empty variable ... so yeah, i'm stuck there <sunless>untrusem-: do you know how to make the container access the gcc-toolchain libraries <futurile>sunless: you said you're a 'beginner' is your goal to learn Rust? or mess with Guix? <futurile>sunless: if you want to spend your time 'learning Rust' then I think you're going to find 'guix shell' pretty frustrating because it's not a standard way to do things. I'd recommend you use a full system container, install a 'standard linux' and do 'rustup' inside that. All the documentation around Rust will be easier at that point. <sunless>futurile: learn enough guix to setup rust dev environment and start learning rust with "rustup doc --book" like normal <futurile>sunless: there's definitely people using Rust in Guix, but it's gonna be a fight from what I see on this channel <sunless>huh, i see ... better cut my losses and checkout working in a podman container <sunless>i'll check-in later whether the fhs stuff is smooth for rust dev environment or they add rustup as a guix package <sunless>futurile: thanks for saving me time and sanity <futurile>sunless: it looks like they are running a CI to grab the rust binary and 'create a package' like nonguix <futurile>sunless: but honestly, I'm an advocate of KISS so yeah a podman or a small vm for your rust dev is probably easiest way to start imho <sunless>futurile: yeah, lemme focus learning programming language first, instead of spending more time with the environment, anyways i appreciate everyone's help <kestrelwx>sunless: With regards to `emacs-docker`, it propagates `emacs-aio` and that propagates `emacs-elfeed`, so that's how you'd get it in your profile. <sunless>kestrelwx: i don't want packages to be forced on me, i'm trying to be minimalistic <sunless>so is there a way i can "get it out of my profile" (emacs-elfeed and emacs-aio) <kestrelwx>I understand that Emacs packages need to propagate the dependencies, so you could make variants that don't have these as dependencies, provided they would work in the first place. <sunless>"(use-package docker :ensure t)" after installing docker.el that way, M-x doesn't have elfeed, but "guix install emacs-docker", it's okay i have M-x docker, but why is there M-x elfeed there? <sunless>kestrelwx: i think it's slowing my emacs, i also need to find the package which also forced magit on me, i'm trying to learn to use vc <sunless>i'm thinking how can i block these unwanted packages or change the EMACSLOADPATH to go back to the normal installing of packages <untrusem->I am trying to package rust-1.91, for that I need rust-1.90 , so I am trying to use inferiors here as I don't want to build rust-1.90 myself -> here is the bit for that https://bpa.st/XTXEI <untrusem->In procedure package-source: Wrong type argument: #<inferior-package rust@1.90.0 7f1bbaa43450> <untrusem->so maybe I am not using the syntax correctly <csantosb>Ey, Guix, I have a serious question here, I'm unable to reproduce a build failure, and I wonder why ? <csantosb>Building locally, on top of the hpc-team branch, with `./pre-inst-env guix build llama-cpp`, it build with no issue <ieure>csantosb, Error in the CI build is: make[2]: *** [ggml/src/ggml-vulkan/CMakeFiles/ggml-vulkan.dir/build.make:89: ggml/src/ggml-vulkan/acc.comp.cpp] Illegal instruction <csantosb>My doubt is about why I don't observe the same locally <ieure>csantosb, The error means the CPU tried to execute an instruction it didn't support, which makes me suspect that the build is emitting instructions for an ISA extension the CI builder doesn't have, but your CPU does. <csantosb>I switch to the hpc-branch, `guix shell -D guix`, then `./pre- ...`, this is the same as ci, right ? <csantosb>ieure: ok, let's try in a 10 years old hardware, it is going to take some time <csantosb>Ok, so now I'm building llama-cpp in different hardware, "[ 16%] Generate vulkan shaders for flash_attn_cm1.comp" <csantosb>I'm unable to reproduce what ci sees, I'm afraid <ieure>csantosb, Does the failure consistently reproduce on CI? <gabber>how can i ping (@) a team in codeberg? <acidbong>if you can't ping them, you can request a review (in a PR at least) <ieure>sigh, `make -j20', then `git push', et "failed to authenticate some commits." Okay, `git co keyring && git pull && git co master && git push'. Now all the files I just built are stale and I have to wait 20m to rebuild everything again. <clone>same feeling as when something that takes an hour to build fails on check or compile stage <newguixbie>new hotel, ci.guix.gnu.org is giving me 504 here, anyone else see that or not? <ieure>newguixbie, Same here. Guix infrastructure is not very reliable. <ieure>There are a variety of similar sites. <ieure>This is not an endorsement of that specific one, just letting you know that there are tools to self-serve these questions. <newguixbie>I actually went there but it says "down for more than a week" and it worked for me earlier today and past few days <ieure>I don't they check it often enough for the history to be reliable, since it's niche. <ieure>(They should probably surface that in a better way)