IRC channel logs
2024-03-07.log
back to list of logs
<stikonas>perhaps gentoo build for guix is missing ncsd dependency then... <festerdam>stikonas: Sorry, I'm a bit confused by that message. I'm on fedora, not gentoo, if that's what you mean. <stikonas>anyway, given your links it does seem that you are right <hapst3r>How do you search, in Guile or Guix, for a function and the module it is defined in? <hapst3r>I was trying to find `sha256` and it drove me nuts because unlike `base32` it is not automatically "pulled in" with the (guix) module it appears. And grepping the repo is a terrible way to do this :D <nckx>hapst3r: I don't think that's correct. It's defined in (guix package), which is implied by (guix). <nckx>(guix packages) oopsviously. <hapst3r>nckx: thanks for confirming what I suspected - yet it is weird autocomplete (vertico/Geiser/emacs) didn't find it after (guix) was loaded. Do you also happen to know if there is a convenient way to find where a function/macro <nckx>I also use grep :-p Never got into the Geiser(y) way of working. <nckx>In thin particular case, I Just Knew. <hapst3r>nckx: Which directory do you grep? I always use ~/.config/guix/current/share/guile/site/3.0 (on a foreign distro) but feel there should be an easier way, since there I always need to use sudo. <hapst3r>And which invocation to you use for grep? Because as you pointed out in your link, it is not via a normal `(define (sha256` Form, which I would've tried next, without success. <wingo>weird scheme thing i don't understand: modify-phases uses replace as a keyword. it is defined in a relatively "clean" module, (guix build utils). notably it doesn't define syntactic keywords for e.g. "replace". however modify-phases is often used in environments that import (gnu packages), which defines replace as a syntactic keyword. <wingo>context is, i extracted a package from (gnu packages containers), and am getting an error: /home/wingo/src/guix/distrobox.scm:55:15: error: (replace (quote install) (lambda _ (invoke "./install" "--prefix" (ungexp output)))): 'replace' may only be used within 'modify-inputs' <wingo>which is as expected, to this schemer: the module imports (gnu packages) so the usage of "replace" in modify-phases should refer to the syntactic keyword, not an unbound identifier <wingo>this is all within a gexp, which perhaps changes things <wingo>anyway how is this supposed to work? <wingo>this is while building with guix build -f foo.scm. dunno what is going on <wingo>fwiw i am now falling back on just editing (gnu packages containers) in place, assuming there is something about that environment that makes it work <civodul>the ‘replace’ keyword of (gnu packages) doesn’t matter here because ‘modify-phases’ is usually in a gexp and (gnu packages) isn’t in scope there <wingo>fyi the file i had extracted did a use-modules of all the modules used by (gnu packages containers), then a straight-up copy of the definition of the distrobox package. <civodul>do you have (use-modules (guix gexps)) in your own file? <wingo>lol i seem to have deleted it already. let us forget about it for now <civodul>when (guix gexps) isn’t in scope, you get bad error reports <wingo>ah that makes sense to me. i guess the reader extension would be installed but ungexp etc would not be in scope <wingo>probably that was it somehow <wingo>maybe i spelled it use-module or something embarrassing <fps>has someone managed to change the init in guix from herd to systemd? :) <efraim>shepherd is too tightly connected to separate it out, but again after reading about postmarketOS switching to systemd I've thought about seeing if we could add a systemd service not as PID1 <efraim>ACTION also waves hi to wingo and civodul <civodul>i’m interested in hearing the main motivation (i can think of several reasons, but i wonder which one matters most) <fps>in my case? it's just that systemd-resolved makes adding dns entries per link so easy ;) <efraim>heh, systemd-resolved was one of the parts I didn't miss :) <efraim>then again I've not played with it that much <civodul>ACTION is not familiar with systemd-resolved <efraim>I wanted the user-level systemd services mostly, but also because it's there and I wanted to see if it were possible <fps>and systemd-resolved just made that much simpler.. <efraim>my only interaction with it was a tutorial to use a debian box as a router. I don't actually know what my other machines running not-guix are using, so its definately possible I'm using it there <futurile>what's the summary explanation of why Guix doesn't work under Docker? And, will Chris rewriting the daemon in Scheme potentially help that? <efraim>I found guix-icons was using %artwork-repository as its source so I'm adding my guix-backgrounds package next to it <futurile>ACTION been fighting with docker to see if there was a way to do pair-programming for patch review <efraim>futurile: Last I remember it needs privileged mode to be able to spawn the build processes as different users <futurile>efraim: yeah - that's fundamentally where I've got to - how did Nix get around it? <civodul>futurile: guix-daemon needs root privileges to switch users etc., unless you pass ‘--disable-chroot’ <futurile>I found someone who used buildx extension to build packages in Docker - it's good for oneshot stuff <civodul>that’s why ‘guix system docker-image’ automatically adds ‘--disable-chroot’ <futurile>I was trying to think of a way that two people could 'pair' to do a patch review - I personally don't want to let someone onto my machine to look at stuff <futurile>I think it's back to the drawing board for me - maybe I will look at 'real' hosts and chroot or something <futurile>or maybe I will just do some patch reviews - because I've spent too long on this already :-)) <fps>can't you have a "root" in docker? i always thought namespaces would give you that <fps>even in unprivileged mode <fps>podman might work better than docker <futurile>fps: I think you're a 'root' within the container. Outside the container it uses Linux capabilities to map the user to a 'normal' user. The guix-daemon runs as a single server for all users, it needs teh capability to 'change to another user' - normal users don't have that right <futurile>fps: in this case I'm trying to run a container I created on a hosting provider (gitpod) - I can't change the way the docker daemon runs <fps>ok, so podman is not an option <futurile>fps: not for this - but maybe I need to set-up a virtual host and then people could login and use podman there etc - not sure if I want to continue down this path :-) <fps>yeah, i have no idea. i just read after a quick google search that podman might make it easier to run something akin to a "full distro" than docker <nckx>hapst3r: My Guix git checkout in ~/guix. Your casual mention of sudo confuses me very much. ~/.config/guix/current/share/guile/site/3.0/guix is a symlink into the store, which is world-legible by definition. It doesn't sound like this is due to Guix, or at least deliberate. <nckx>I don't use any fancy grep secrets. In this case, I don't know exactly what I'd have done if I hadn't known the answer. Definitely confine my search to the guix/ (package manager) subdirectory as opposed to gnu/ (the distro), and then probably just grep for sha256 and just... read... :-/ <jpoiret>how does everyone do their big merges using magit? ediff? I'm having trouble when I need to blame versions A or B, since they're not visiting a file buffer magit-blame doesn't work :( <jpoiret>properly merging master back into c-u is ... challenging to say the least <janneke>ACTION never merges, always rebase and rewrite <janneke>i often look at the patch being applied, often it's just a single word or line that's changed <jpoiret>heh, for c-u that's quite a challenge though <jpoiret>i mean, because it's a "published" branch, you don't want to rebase on top of master <jpoiret>esp. since it's been merged before already, and also there are hundreds of extra patches on top <cbaines>you could see a branch as a collection of patch series though, at which point you can just regenerate the branch against a new master <jpoiret>cbaines: that's what I'd prefer as well <jpoiret>but you'd lose all the conflict resolution when applying those patches again <cbaines>you can do the conflict resolution in the individual patch series <jpoiret>we'd need to re-send updated patch series all the time <jpoiret>some patch series are a year old at this point :( <jpoiret>but I guess that's how Linux does it? <cbaines>but anyway, I think I use [merge] conflictStyle = diff3 in my gitconfig which might be useful <jpoiret>Ediff also has very nice highlighting of differences once you start a session (E m in magit) <cbaines>There's also C-x v ~ which allows viewing a file at a specific revision, which can be helpful when merging <civodul>ACTION tries to avoid big merges by merging frequently :-) <jpoiret>civodul: couldn't avoid it with some big branches being merged recently <efraim>the rust branch is easy if you're the only one working from it ;P <jpoiret>we also had c-u specific patches on it. <jpoiret>meh, it's done now, we'll see if I can build again <janneke>asking for help is often a good idea :) <jpoiret>goal for today is running c-u on my laptop <janneke>jpoiret: has guix copy been fixed on c-u yet? <janneke>well consider this, a heads-up then :) <bonni>Hello, I try to run software in a guix container that I created with 'guix shell -C'. When installing the software inside the container it complains about not having enough disk space. How can I increase the space available? I am writing to the current working directory <janneke>ACTION had been trying to hunt down guix copy/offloading problem to a core-updates hurd-vm for quite some time, only to find that it's also broken with a linux vm <janneke>(building a linux vm was been broken for quite some time) <efraim>the "is it only me" question, which can also be phrased as "can this actually be someone else's problem?" <civodul>jpoiret: yeah, that strategy is not always applicable unfortunately <futurile>bonni: 'guix shell' doesn't limit how much disk space you have available AFAIK. Are you sure you have enough space on the volume without being in the shell? <bonni>futurile: yeah I just realizes I messed up a path, it all works as expected <jpoiret>civodul: with 01f685d56016ae529381a73daedccc1949b808ec I get "gnu/home/services/dotfiles.scm:66:0: warning: possibly unbound variable `serialize-list-of-strings'" <jpoiret>omg. literally rebuilding all of the world *yet again* <futurile>bonni: cool - always best when it's something simple! <futurile>I was thinking of some cool GSoC projects: was thinking about the Guix Repl/nRepl experience; Docker image creation/optimisation; intergrating sandboxing for desktop apps (e.g. flatseal). Anyone interested in mentoring on those areas? <bonni>on a somewhat related note - I am using a manifest.scm to setup my container, is there an option to also set environment variables in there? or should I use something like direnv for that? <Zzull>Hello everyone, is there any Emacs shell user in the area? I've been struggling with it since the last Emacs update in october. `sudo` through `tramp` doesn't seem to be working anymore. Has anyone also witnessed it? I would like to know if it's coming from my Guix configuration. <futurile>bonni: oh good question - technically you could do it in a manifest I think as it's 'just' guile scheme - but using direnv is popular - there's some videos by Andrew Tropin where I think he uses direenv <futurile>bonni: often --expose=/etc/ssl/certs if adding nss-certs doesn't work <futurile>it's an interesting problem area - I need to read that post in more detail acrow <qecep>hello, i'm having a major misunderstanding in how things works, so i want the alsa service and environment to be set, i added audio to use-service-modules but if i add to my list of services service alsa-service-type it give an error about a double asoundrc and alsa is still not working properly <acrow>futurile: I hope the people at CISA read it! <erikeah>I'm trying to create my own guix.scm to be used with guix shell, however I got stuck while trying to inherit from node and change de version because once I get inside shell and I execute 'node -v' I get another version. For testing take a look to my file: https://paste.debian.net/1309764/ <erikeah>I suspect that I'm doing something wrong <erikeah>I do not understand why node-lts version is installed instead of mine <flypaper-ultimat>erikeah: you either want to specify a transformation, or you should change the source in node-21. <flypaper-ultimat>erikeah: right now the "source" of node-21 is the same as node-lts, including the url where it gets it, which was locked in to "18.19.0" when it was defined <qecep>I think I fully installed alsa, so alsa-utils alsa-libs alsa-plugins ao, should be all right? I searching with herd for the service to try start it manually but nothing, herd restart sound or alsa or alsa-lib does't find anything, so guix system reconfigure keeps slapping me with "guix system: error: duplicate 'asound.conf' entry for /etc" <qecep>I don't know where to bang my head anymore, i've followed what's documented but I'm stuck <flypaper-ultimat>(see (info "(guix) Defining Package Variants") the bit how it does the 2.2. of "hello") <RavenJoad>Does Guix have a way to set environment variables automatically upon entering a "guix shell"? I want to set INFOPATH, LD_PRELOAD_PATH, and others with paths from $GUIX_ENVIRONMENT upon entering the shell. <erikeah>flypaper-ultimat: thanks! Do you know any way to avoid define sources again in my guix.scm? <rekado>RavenJoad: you could use env: guix shell coreutils python -- bash -c 'env LD_LIBRARY_PATH=$GUIX_ENVIRONMENT/lib bash' <flypaper-ultimat>you can do it like a transformation, but then guix will check it everytime if its the same, something like the output of `guix shell --export-manifest --with-version=node=21.7.0 node` <old>Is there a TTL for substitutes in build farms? <old>for example, if package P is updated from version A to B. when will the buid of P.A not be available as a substitute on the build farms? <civodul>old: bordeaux.guix keeps everything since it was started (cbaines can correct me if i’m wrong) <civodul>ci.guix has a sloppier policy, right now it keeps nars 180 days after the last time someone asked them <old>Because I was wondering. If someone use the time-machine to reproduce some scientific paper, the package might not be available anymore after X years <old>and so, it would be a very huge pain to rebuild the entire system <civodul>which is why i worked on ‘virtual-build-machine’ <civodul>a service to build things “in the past”, “in the future”, on a different CPU, etc. <old>and how would that help for very long term paper? <old>like it packaged a VM image with all the image at point X in time? <civodul>we’re talking about a time frame of years, not decades <civodul>archival is a completely different thing IMO <old>I see one problem with virtual machine tho, but this is a larger problem. Time benchmark are not very meaningful in a VM <old>But anything time related is not trivially reproducable across micro-architecture <civodul>right, but performance benchmarks are complicated anyway <old>I guess that for "true" long term archival, it would be interesting if journal would keep build farm for the published papers <lispmacs[work]>hi, I'm trying to explore the question of whether a system that uses luks-device-mapping is reproducible. I came up with a very basic OS definition, where root filesystem targets a mapped device of type luks-device-mapping. I can build this OS with guix system image and with guix system vm, but in both cases all the configuration pertaining to that is just ignored, and the system is installed to /dev/sda or to a 9p <mgd>Hello again. I managed to finish the install of Guix on a Thinkpad X220 connected via ethernet. The `guix pull` command took forever still but I appreciate this happens the first time. I've enabled substitutes as per the GUI installed but installing a package and running `guix pull` again still takes more than 10mins to complete. Am I doing <mgd>I plan to use it as a package manager over Arch to test this further <^chewie`>mgd: Doesn't sound like it. Took quite a while for my old Dell Latitude E7250 this week. Currently, I'm in ERC on that laptop now. <^chewie`>mgd: Using it as a foreign distro? I had thought about doing that for my other laptop, my daily driver, a Debian Dell XPS. The whole dotfile with stow + guix home configuration as a unifying experience between the two machines sounds like a fun experience. <^chewie`>mgd: once comfortable w/guix as a system, I'll probably re-install the Debian laptop w/guix <mgd>^chewie` interesting. Did you have to do anything to work with non-libre hardware? How long does updating take you? <^chewie>(I need to figure out how to keep dropping due to ping timeout in ERC) <^chewie>mgd: I first did an install via the guided method with a wired connection, just to see how it worked out. <^chewie>mgd: Overall, the experience has been pretty good. There's a weird issue with my laptop not seeing the EFI boot partition paths correctly upon the first installtion. I had to delete and re-add the path on the drive via BIOS settings. <^chewie>mgd: I thought that'd be the end of the problem, but subsequent reconfigure calls also makes the BIOS "forget" where the path is. Very strange. <^chewie>mgd: I still see it as a win and a small wart in the experience. For less than $100USD, I resurrected this old laptop to live again and got to test-drive this awesome system. <futurile>does anyone use git worktree for guix development? If you do, do you ./bootstrap;./configure in the main 'checkout' or in each individual worktree? <futurile>I'm having to .bootstrap;./configure;make in each worktree which is annoyting <RavenJoad>rekado: Ok. I was hoping for a simpler solution, where I can put the new values for the environment variables in a file, the same way Nix shells can. But if that is the only way to do it, I can do that. <^chewie>futurile: Isn't that how git worktree works, fundamentally? You're creating a workspace for each branch in separate directories which are only tied to each other by git history, not working environments. <futurile>^chewie: yes probably makes sense- annoyingly so as it's taking too long =-) .. but makes sense <mgd>^chewie totally, my laptop costs next to nothing but i've done loads with it with Arch. seems to be running quicker over Arch <aarcov>I've got some minor updates to some rust packages I'm getting ready to send in. The a few were version bumped and then I also enabled building and testing for the packages (which required setting `RUSTC_BOOTSTRAP=1` so that they could be built with nightly/dev branch features rather than downloading them only). What branch should I send them in to? I'm looking at https://guix.gnu.org/manual/en/html_node/Submitting-Patches.html, and I believe these are likely <aarcov>non-disruptive changes (althought the bootstrapping might be something for review); I was also under the impression that Rust packages might be sent to their own branch first (and I'm not seeing that here). <aarcov>The list of modified packages is: <rekado>RavenJoad: you can also put them in a custom bash init file <rekado>futurile: my worktrees are long-lived, so having to do the bootstrap is only annoying once <rekado>RavenJoad: I think it would be neat if "guix shell" could be extended to set variables on its own, or to otherwise influence the sub-shell invocation. <futurile>rekado: ah maybe I'm making a mistake - I've been making one 'worktree' for each issue <graywolf>When try to run `guix lint' from `guix shell -CWND guix -- ./pre-inst-env ...', I get an error about certificates. When I get nss-certs, I now just get 500 error. Only after I also add openssl package, it starts to work. <graywolf>Should those packages be added automatically since they seems to be required? <vagrantc>futurile, rekado: i try to keep my worktree long-lived, but periodically i find i have to re-run the bootstrap process <futurile>vagrantc: OK, that's a second vote for long-lived them - I'm going to change what I'm doing! <vagrantc>futurile: they are never as long-lived as i would hope, though :/ <efraim>I apply the patches against whichever branch I'm applying them to <podiki>good discussion in today's patch review meeting? i hope to make one soon! <efraim>I need to see if I can screenshare with my setup, and see if my upload speed is enough or if I would need to tether <podiki>i just moved to wayland and haven't seen if i can screenshare or what <jackhill>podiki: yes you probably can. What wayland set up do you have? Likely you'll need pipewire and maybe a desktop portal <podiki>jackhill: i do have pipewire and desktop portals; trying out hyprland which might need its own portal as well. i haven't had a chance to try really though <jackhill>podiki: xdg-desktop-portal-wlr's share/sdg-desktop-portal/portals/wlr.portal claims it supports Hyperland. You may need to set XDG_CURRENT_DESKTOP=Hyprland depending on how you're starting it. My understanding is that var is how the portals know which actual executables to invoke. <ryan77627>Hi all, quick question. I use Hyprland (I presume this may be the same for sway, didn't check using it) and when I "logout" (use the exit shortcut I have set), shepherd doesn't kill my user's processes. This is an issue because when I log back in, it doesn't realize they are running and spawns them again. This is causing havoc with dbus and pipewire communication since I have multiple instances of <jackhill>and I don't remember if pipewire screenshare is still behind a settings flag in our browsers or not <podiki>jackhill: thanks! will see about setting that XDG setting, have seen it come up for wayland stuff <podiki>ryan77627: i don't think i've noticed that issue, hyprland and sddm as login manager. or at least dbus and pipewire seem to run fine still <ryan77627>podiki: maybe because I don't use a login manager, I just login thru the tty and have a script set to auto-launch Hyprland if in tty1. They still "run fine" at the end of the day, everything works, per se. I just notice it when I connect BT headphones since the message from bluez -> pipewire/wireplumber gets lost and I presume it's because I have 10 sessions of each running <podiki>could be; i'm not familiar with running wayland stuff much, more use to X <ryan77627>that is fair, i saw your discussion above regarding portals and such. Speaking of, I packaged the hyprland portal if you want to use that. Right now it's in hako <ryan77627>hako's Rosenthal branch but is a bit broke, haven't had the time to submit a PR to fix that quite yet. can describe the change if you want to use it <podiki>i haven't tried out the hyprland specific portal yet, but do use the hyprland package from that channel <podiki>we should have what we need to upstream everything once mesa-updates gets going (new libdrm mainly) <RavenJoad>rekado: It would be very nice to have just a single file that records those environment variables must be set. It would require an extension of some sexp format, since manifests do not allow environment variables to be set. <ryan77627>podiki: fair. I'd be more than happy to move anything hako doesn't move upstream whenever hyprland is upstreamed :) <ryan77627>I've been meaning to do bluez for the last few weeks to a branch but I've been busy :/ <podiki>they are also a committer to guix so I'm hoping it makes for an easy process once we have the necessary updates :) <hapst3r>civodul: Is there a way to Highlight in devel manual what is actual devel Material and what is regular (i.e. stable) manual Material? I am not talking about a changed sentence, but sections not present in stable but present in devel (like the section on virtual build machines earlier) <apteryx>hapst3r: no. these are the same manuals, devel is simply being the most current one <apteryx>the manual is shipped along guix, so devel is what you'd locally get following a 'guix pull' <ryan77627>Yeah, definitely seems shepherd doesn't kill my services on logout. I ran a `ps aux | grep ryan` after I killed all my sesisons and sure enough all my services were still there. Maybe this is by design, I need to read the Shepherd manual. I know systemd (maybe logind?) has an option to kill processes when logging out. <jpoiret>ryan77627: I have the same problem. Thought it probably was an issue with logind's linger mechanisms, waited for more than the default 10s (I think) before relogging but it didn't change anything <jpoiret>haven't looked too deeply into it though, because I never log out without rebooting :) <jackhill>jpoiret: are you aware of any guide about "this is how all these XDG/freedesktop peices are supposed to work together?" My (limited) understanding is mostly based on reverse engineering and documentation fragments, which is less than satisfying. <jackhill>on my personal wishlist for figuring out: a sway (/hyperland) lock that interacts with the GDM/Gnome mechanisms to facility user switching so I can share the computer with my family :) <jpoiret>jackhill: I don't think you'll be able to interact with GDM in a standards-compliant manner <jackhill>singpolyma: perhaps I need to peruse those again now that my understanding has increased, but I think I'm still in need of "so you're puttinga desktop together from disparate parts, refer to these other documents in this order" <jackhill>jpoiret: heh, well, I don't need it to be standards based, just to work :) Well, it would be nice for their to be a standard, but… <jackhill>alternatively, GNOME to interact well with another DM, but I'm not holding my breath. <jackhill>what I want may actually be a minimal GNOME-Shell instance… <jpoiret>in general, logind is the place where it's at. I simply moved to simpler to understand greeters/lockers when I realized GDM is just a humongous pile of spaghetti <jackhill>does GNOME work well with non-GDM? The end result of GDM is nice (at least when we haven't broken it (i.e. accessibility)) but yeah don't look behind the covers <jackhill>anyway, as you can tell, I don't fully understand all the components yet <aarcov>For rust crates, I'm assuming Software Heritage doesn't archive them if they are from crates.io (as it isn't a gitrepo); would it be advisable to change packages to use a github (or provider) url so that these packages are archived automatically by `guix lint`?