IRC channel logs
2024-12-12.log
back to list of logs
<eikcaz>And yeah, I figured as much. Guess I just want to be 1000% sure <vagrantc>very useful for checking for reproducible builds ... in some ways better than guix challenge <janneke>/gnu/store/ssnlw0nnjqnvxqclxzdwxpig10la6diz-python-numpy-1.26.4 <basicnpc>What happens when I install a package X, which has a propagrated dep Y.. but I have had Y-2.0 in my profile already? <basicnpc>Btw, why doesn't guix channel usually keeps package definitions with older versions? Say now emacs is version 29.4 there, but there isn't 29.3, 29.2 ..etc anymore. <ieure>basicnpc, I don't know the machinery, but it's something like that. <wakyct>otherwise maybe the mailing list? <wakyct>but at that point you've probably done half as much work as packaging it yourself and sending a patch ;) <PotentialUser-2>I did check both of those. And I've tried to package it before but failed. <PotentialUser-2>It's a Rust app and I don't really understand how those are packaged <basicnpc>I have "ctrl:nocaps" in the #:options of keyboard-layout, ran `guix system reconfigure file.scm`, rebooted, but capslock is still capslock.. <basicnpc>Oh.. seems like because I'm using GNOME, which overwrites it. <csantosb>Ey Guix ! This is strange: in a new remote image, I do a `guix install docker containerd` <csantosb>`ls ~/.guix-profile/bin` returns "containerd containerd-shim containerd-shim-runc-v1 containerd-shim-runc-v2 containerd-stress ctr dockerd dockerd-20.10.27-ce" <csantosb>`uname -a` gives "Linux build 6.11.11-gnu #1 SMP PREEMPT_DYNAMIC 1 x86_64 GNU/Linux" <Rutherther>docker command is in docker-cli. But you won't be able to install docker like this <Rutherther>docker needs system support, you can't just guix install it to a profile <csantosb>Why not ? In my local laptop I get "docker dockerd dockerd-20.10.27-ce" under ~/.guix-profile/bin <Rutherther>I am not saying it won't be there, but that you won't be able to make images/containers with it <csantosb>Rutherther: to make containers we have `guix pack -f docker`, right ? <Rutherther>I meant run containers, not create them. For creating them you can use many tools, including guix pack to pack guix profiles, yes <csantosb>My intention is to just create, load the container and push it to a registry, just simply <rekado>csantosb: use containerd-service-type and docker-service-type <efraim>you don't need to install anything into your user profile to use guix pack -f docker <Rutherther>you cannot load the container, since there is nowhere to load it to. For that you need to run docker service <csantosb>`sudo dockerd &` is not enough ? ... only the time to do a `docker load < $image; docker push ghcr.io/...` <csantosb>Ok, no, I have a "failed to start daemon: Devices cgroup isn't mounted" (locally in foreign config the trick works) <dariqq>Great, third problem caused by the guile-ssh update: guix copy: error: failed to authenticate server at '*': not-known <efraim>janneke: here's what I currently have for core-package-team https://bpa.st/FUOA, not sure how to apply it without causing you rebuilds <janneke>efraim: nice -- i have "only" 253 packages to go for my system build, which includes 180 texlive packages... <janneke>efraim: what we could do is move the current branch to core-package-team-old again <janneke>cleanup and squash the current branch, including your patch <janneke>efraim: ...have you seen my remark yesterday? <efraim>I'm still blocked at bash-final on most of the architectures <janneke>i believe the gcc.sh wrapper fix that we have in gcc-final must be moved to gcc <janneke>because gcc-14 won't build gcc-11 (and moste probably also wont' build gcc-4* gcc-5* without that wrapper <efraim>I did. I think that'll make it easier to have it over there rather than added everywhere <efraim>I'd also like to drop gnu: %bootstrap-glibc: Prevent rebuilds. before the end <efraim>I wonder if REMOVEME-undo-bash-minimal-CFLAGS-change is the bash I'm having trouble with <janneke>re gcc, i'm kind of afraid changing an early gcc package (gcc-4.7?) will impact early commencement, like gcc-2.95 etc, so i was hoping we could find a smart way around that <efraim>if we add it as a new self-contained phase it can be removed elsewhere <efraim>ekaitz and I also discussed about redoing the GCC inheritance chains to make it clearer what phases and arguments there actually are for each different gcc based package <efraim>so if it's in a self-contained phase that'd be easy to remove if it's not necessary (make wrapper, setenv, etc) <janneke>i've been trying to start an email discussion about inheritance impact of base packages on commencement, but i'm the only poster atm :) <janneke>i had to patch bdb-5 early on, an now "near the end", a dependency on bdb-4 pops up => boom, world reboot <efraim>I think part of why commencement is so scary is because almost every package is inherited and has arguments not seen elsewhere (implicit-inputsβ½) <janneke>efraim: i'm going to move core-package-team to core-packages-team-old and squash & cleanup core-package-team right now <efraim>I need to figure out what I did with my riscv64 bootstrap branch and get it working again so I can say "this works and can be merged" and see what can be pushed off to later <janneke>do you want to have "gnu: %bootstrap-glibc: Prevent rebuilds." marked with REMOVEME in there? i'm tempted to drop all REMOVEME patches so that we may work on this gcc and your early bash problems <efraim>yeah, you can just mark it as REMOVEME and drop it later <efraim>it didn't take long to build that early in the tree <janneke>okay, then i'm dropping it together with the other REMOVEME commits for now <janneke>efraim: cleaned, rebased, and world-rebuild-ready core-package-team pushed <janneke>headsup: i want to move the gcc.sh wrapping to gcc-4.7 some time soon <ekaitz>i agree with both of you efraim and janneke <ekaitz>the inheritance part is a huge problem in commencement <ekaitz>we should isolate it from the rest of the system <janneke>hmm, /me also wanted to use no-error= throughout, oh well, another round of squash commits then... <csantosb>Hum ... a reconfigure of the remote sr.ht guix image running during an hour or so ... <mccd>Heya, is least-authority-wrapper the way to go if you want to wrap a program in a container? <janneke>ACTION moves create-stage-wrapper stage to gcc-4.7, makes it self-contained, and watches another new world arise <janneke>checking for gcc... /tmp/guix-build-gcc-cross-boot0-14.2.0.drv-0/gcc-14.2.0/gcc.sh <janneke>checking whether the C compiler works... no <janneke>c'mon, we already built gcc-final with this wrapper, help a bit along computer! <janneke>w00T -- /gnu/store/1s15p6mx6r1vn0f3g8jpq5wgxdq99l8f-gcc-cross-boot0-14.2.0 <janneke>(and will the hurd cross-build still build...worries for later) <janneke>wow, dblatex->inkscape->lipsoup->samba <janneke>now, who needs dblatex in my system config? <janneke>-> /gnu/store/ry1lwq8fdi9p6m2mvq447ba3cnspp6ki-gtk-doc-1.33.2.drv <janneke>many do, but ugh: network-manager-1.44.0.drv udisks-2.10.1.drv? <janneke>should be possible to get networking without gtk/samba? <janneke>even using network-manager, that has a tui too, right? <apteryx>janneke: the samba/sane dependency in gtk is annoying <janneke>yeah, and libraries/utilities like udisks, libnotify, network-manager, iwbn if they had a smaller closure <janneke>(or had variants with a smaller closure) <janneke>we need a team for trimming closures <futurile>don't forget it's Guix Social tonight - with a talk by Christine Lemmer-Webber - 18:00 UTC <futurile>fnat: I'm just replying to you about the survey - short answer is I've been travelling - but will be home next week so will have time for it <fnat>Ok, excellent, no hurry, I was just curious and figured someone might ask. :) <futurile>I guess my plan is to go through the data, create two blog posts. Then publish those on the Guix blog, and publish the data so others can take a look. <futurile>fnat: weirdly I can't boost your post about the talk tonight <apteryx>futurile: sounds fun; a bit in the dead of the night here so I won't make it though :-/ <futurile>apteryx: ack ack - sometimes we manage to get a recording that's good enough I can put it up after some editing! <fnat>futurile: Ha! Right, I mistakenly posted the thing as followers-only, sorry, now reposted as public, you should be able to also repost it now, if you like. <futurile>ok, I have to run - have a good guix social tonight fnat! :-) <mccd>when using the least-authority-wrapper, I run into the issue that it seems to not connect to network, is there a way to allow the program internet connection? <fnat>mccd: Did you add something like '(requirement '(networking))' to the service definition? <mccd>fnat ah I did not. Hmm, I'm using simple-service, is it possible to add that requirement still? <mccd>or will I need to make a new service <fnat>mccd: Hm sorry, actually having a second look at it, it might be something like this? '#:namespaces (delq 'net %namespaces))' <janneke>efraim: just pushed gcc-wrapper => gcc-4.7 patch to core-package-team <janneke>i've asserted that gcc-final still builds <fnat>Have you tried looking at one of the existing least-authority-wrapped services? <janneke>there are also some "prevent rebuild world" commits <janneke>efraim: i'm halting here for a bit, so feel free to push world any rebuild commits <janneke>you/we may want to undo the "prevent world rebuild revert" commits whenever the first world rebuild commit has landed <janneke>ACTION is only 9 packages away from "hello" again on core-package-team <janneke>ACTION knew it, they'r waay to productive to be one human <mccd>fnat heya, adding (delq 'net %namespaces) worked. It does now complain about tls "TLS certificate verification failed: The certificate is NOT trusted". Maybe something with ssl certs missing <fnat>Oh ok, glad to hear that solved at least part of the problem. <dariqq>hmm i htink my guix copy error is from guile-ssh using the wrong port to connect to <dariqq>oh god, It looks like guix copy never should have worked that way but it did anyway until now <graywolf>dariqq: "It looks like guix copy never should have worked that way" wdym? <dariqq>graywolf: #74832 : guix-copy assumes port is 22 when no port is given but previously guile-ssh silently ignored the given port with the one from ~/ssh/config <graywolf>Oh yeah, this bit. Yeah, the ignoring of explicitly passed ports was annoying <graywolf>So I am glad that part is resolved, there is some fallout however (as we both found out) <dariqq>I think the best solution would be to just use #f as a port unless it is specified and leave that to guile-ssh to figure out . From my limited testing it seems to fallback to 22 by itself <graywolf>I am just going through all uses of open-ssh-machine to make sure all are correct before sending a patch <dariqq>But greping through the guix tree there are many (or port 22) or similiar constructs all over the place <janneke>efraim: headsup, i've promoted the bash gcc-14 fix to be used by all architectures and removed patching static-bash-for-glibc, locally <janneke>really hoping that will help other arches too <janneke>the message here being: /me doing commencement world rebuild cleanup stuff :) <graywolf>I see it exports %test-openssh, %test-dropbear, but grepping for them gives no call places... <jsbiff>Hey all, I'm using guix as a package manager on Debian, and installed emacs. I then installed a couple emacs packages also using guix. Now those packages (and the dependencies they automatically installed) all show up twice in the emacs built-in package manager. Is there a way to fix this? Is this a defect I should report? Do I report it to guix or <jsbiff>to emacs developers? I'm not sure what the root cause of the duplication is. <dariqq>jsbiff: What is your $EMACSLOADPATH? It might contain duplicate entries <jsbiff>dariqq: (I've redacted my username in the following): <jsbiff>EMACSLOADPATH=/home/username/.guix-profile/share/emacs/site-lisp:/home/username/.guix-profile/share/emacs/site-lisp <jsbiff>So, interestingly, the directory is duplicated <jsbiff>Could that be why the packages show up twice? Because the same dir is listed twice in that path? <jsbiff>Note that I did not manually setup that path <jsbiff>that duplicate env variable appears to be coming from .guix-profile/etc/profile <jsbiff>So, this looks like it very well might be an instance of the bug 23118 that dariqq linked above <jsbiff>The line from .guix-profile/etc/profile is: <jsbiff>export EMACSLOADPATH="${GUIX_PROFILE:-/gnu/store/aw9nzpanmzpnf0j3fdh6vlv05d95si6c-profile}/share/emacs/site-lisp${EMACSLOADPATH:+:}$EMACSLOADPATH" <jsbiff>If I'm reading that right, it should only end up duplicated if it was already previously defined elsewhere <jsbiff>So far I haven't found anywhere else it was defined <jsbiff>Unless, maybe this is a recursion issue <Rutherther>Are you sure you havent sourced the profile twice? <jsbiff>Rutherther I haven't sourced it at all I don't think. . . because it's already being sourced by profile scripts <jsbiff>But, I wonder if when I ran guix to install either emacs, or those two packages, if guix automatically sourced the file, causing a recursion <jsbiff>So that it ended up sourced twice even though I didn't manually source it <Rutherther>That is what I meant. Are you sure it is not sourced twice? <jsbiff>So, I logged out of my shell, logged back in, and now EMACSLOADPATH only shows the dir once <jsbiff>Somehow it's getting sourced multiple times by guix <jsbiff>as a side effect of installation <jsbiff>Ok, and now those packages only show up once in emacs. Thanks! <Rutherther>freakingpenguin i think returning something is fine for early exit <freakingpenguin>Rutherther: Thanks, I guess let-escape-continuation is the best option for that? <jsbiff>So here's a question: Is it a bug in emacs that it will list packages multiple times from the exact same dir? I think emacs should be smart enough to not scan the same dir twice and not add the same packages twice from that dir? Should I report this to emacs as a bug? <jsbiff>Or maybe not a bug, but a feature request? <unmush>I would think it would suffice for emacs to remove all instances of a directory after the first in the load path <jsbiff>Thanks for your help. Have a good afternoon/evening/or whatever your local time is! <lynn_sh>hello, im looking to remove network-manager-applet from my %desktop-services for personal reasons, but it does not seem to have a service-type name that i can easily delete (such as (delete gdm-service-type)) how would i remove this service? thanks <ieure>lynn_sh, Probably need to use the `remove' procedure to loop over your service list and return true for the one whose name matches. <lynn_sh>i tried that but i guess i am not very good at writing this sort of code. <ieure>Can you paste what you've got? <lynn_sh>i deleted the attempt awhile ago but i can try to recreate it. it's preventing me from booting into a visual mode so ive been doing it all tty <ieure>lynn_sh, I *think* you just want (service-name service). I could be wrong. Have to run, but suggest experimenting in the REPL. <freakingpenguin>In your example you have %desktop-services outside the (remove) expression <lynn_sh>having to do this in tty without paredit-mode is really busting me up <lynn_sh>i think your example worked. im running now. <lynn_sh>freakingpenguin thank you so much for the code review it is working now yay :) <ElephantErgo>Hey everyone, I'm having some trouble with a custom package definition. I'm trying to build a version of llama-cpp with ROCm support using hipamd from the guix-hpc channel. I'm getting a strange error. <ElephantErgo>guix package: error: guix/transformations.scm:1149:4: package `llama-cpp-hipamd-gfx1010@0.0.0-b4137' has an invalid input: #<package hipamd@6.2.2 amd/packages/rocm-hip.scm:136 7ff51096fc60> <ElephantErgo>Does anyone know if I'm missing anything obvious? I can of course provide the full package definition source, I'm mostly just wondering if I'm missing something obvious first. <ElephantErgo>Shoot. So that's why ERC didn't want to send whitespace lines by default. Sorry everyone <mange>Can you put your definition in a paste? <mange>Hmm. I've seen that error before when I mix two styles of inputs (like (list (list "foo" foo) bar) or whatever). That doesn't seem to be your problem here, based on looking at the llama-cpp definition, but you could try adding the input as (append ... (list (list "hipamd" hipamd))) instead? <mange>That shouldn't work, but it might. :P <ElephantErgo>guix package: error: guix/transformations.scm:1149:4: package `llama-cpp-hipamd-gfx1010@0.0.0-b4137' has an invalid input: "hipamd" <ElephantErgo>This gave me a string instead of a package object as the error this time, which is sorta interesting. I'm not sure if it gives me a lead, but it's interesting <mange>Can you put the full error you're getting in a paste? I'm trying to look at the Guix source to see where it's going wrong, but I don't have enough information to find out right now. <mange>I mean, I'm also in a meeting, so keep your expectations low. :P No promises, unfortunately. <ElephantErgo>That is unfortunately the error in its entirety, unless there's some sort of way I can make it more verbose. π€ Absolutely no worries on delay or lack of capacity to help right now, I'm just really thankful to have a second pair of eyes on this at all π <mange>Ah, I was hoping there was a backtrace. Alas. <mange>llama-cpp only has python in its inputs. Could you set the inputs of your package with (inputs (list python hipamd)), just to remove one layer of potential issues? <ElephantErgo>I actually just tried exactly that, and it is now failing at the configure step! That's way better! We have an actual build log now, and the problem is likely something much more identifiable and likely more my fault now ππ <mange>Great! I mean, confusing, but great! <ElephantErgo>I would love to pull in the inputs programatically, but this at least tells us that the main problem I was getting earlier was caused by that and not by something in the definition that's harder to compensate for π <simendsjo>Is it possible to setuid a binary in a package definition?