IRC channel logs
2024-06-26.log
back to list of logs
<apteryx>I think gnu.org infra is down at large currently <cbaines>:( data.qa.guix.gnu.org is stuck processing revisions because something is doing network I/O with no timeout <cbaines>although nothing should be network dependent, so maybe some checker is missing from %network-dependent-checkers <efraim>I have to find the helpful chart you made before. I was going to suggest turning off the build processes temporarily to see if that was using network but I don't remember if that would even be helpful <ngz>Uh oh! It appears I left a big bug in the "tex-team" branch. May I reset it (after a rebase if appropriate?) to include the fix, or would it be too strenuous for bordeaux at the moment? <cbaines>ngz, I haven't replied to the thread yet, but there's not really a problem with pushing to tex-team <cbaines>especially at the moment, data.qa.guix.gnu.org is stuck running the synopsis lint checker, so it won't be processing anything anyway! <efraim>cbaines: in theory would running the linters be faster if there were fewer 'hits' for things to fix? or is it a fixed time based on the number of packages? <ngz>That's good news… somehow… <cbaines>efraim, maybe a little faster, since the data service wouldn't have to record the details of the lint warnings <efraim>ACTION wonders if there's a way to spin it to "encourage" people to fix lint issues in the name of improving QA <ngz>I can help for lint issues, if needed. <ngz>But, obviously, your question is more general. <civodul>cbaines: does ‘check-synopsis-style’ go through the network? <civodul>i think the right course of action is to get rid of that condition <ngz>Interestingly, the Guix manual explains how to generate various `lua-socket' packages with a function, but provides none in the package database. <sepeth>Hi there, I am trying to install Guix to a disk via live CD on an aarch64 VM. It is on a foreign distro, so I am not sure about the `herd start cow-store /mnt` step in the Manual Installation section in the documentation. To give it a go, I installed shepherd via guix, then run the command, but got herd: error: service 'cow-store' could not be <sepeth>found. Do you know how this can be solved? <mehrad>Hi folks. I'm a bit confused with the Guix CLI. I use Guix on a foreign distro and I use guix in two ways on the same machine: using `guix install` or `guix shell`, or using the time-machine (the main reason I use guix). <mehrad>I want to do something analogous to `apt update && apt upgrade` (or in Arch `pacman -Syu`) <mehrad>I have been using `guix pull` and the restarting the systemd daemon of guix, but I don't think this is the correct approach <nikolar>by doing guix pull, you're doing the equivalent to pacman -Sy or apt update <nikolar>if you want to update the packages, you need guix package -u <mehrad>Today I read somewhere that due to the differences between `~/.guix/profile/` and `~/.config/guix/current/`, I have to use `guix package -u`. <mehrad>nikolar: Thanks for confirming my hypothesis <ngz>(or guix upgrade, which is an alias) <mehrad>now two questions: 1) when doing `guix package -u`, does that automatically update the `~/.guix_profile/manifest`? 2) does that affect anything in my guix time-machine (considering that I have the channel file with specified commit hash)? <jakef>guix pull will pull your channel where it is pinned, if it is pinned <mehrad>jakef: That far I understand, but because I don't see any channel file in `./guix_profile/`, I'm a bit confused. Does it mean that it follows the HEAD of the master branch? <jakef>if you don't specify a commit then yeah it pulls from HEAD. if you want to locate your channels file, it might be in /etc/channels.scm or ~/.config/guix/channels.scm <mehrad>jakef: Thanks, but neither of those paths contain such channel file. Is is safe to assume that there is not channel file for the default guix profile? <Deltafire>mehrad: no file needed for %default-channels <atugard>Trying to install with GUI installed and erroneously says no space left on device <atugard>Hhwut in the world is this all about ? <atugard>"That operating system aint right," speaketh the King of the Hill. <atugard>Using 1.4.0 iso to install through GUI installer**, and getting that disk is full when the mnt boot phase comes when its not??? <atugard>Having this issue with the live disk . <atugard>I've wiped the drives and am trying to do a fresh install. <atugard>I dont know how there can be no space left. <atugard>I was having the same problems when I last did a guix system reconfigure /etc/config.scm <atugard>I wonder if it has to do with some layers of memory that are still there even when you wipe the harddrives ??? <atugard>I dont know. Some things I can do in BIOS to fix it ?? <atugard>I think if I can drop to a shell and remove some folders then I can proceed <JetpackJackson>i wonder if i should use guix to install some packages that are not necessary for the functioning of my foreign distro (ie not base or the kernel), but that i would normally otherwise install with my distro package manager... i could even make a bunch of manifests for it <lfam>Interesting that changing the bcc package changes the git derivation, although `guix graph --path` reports no path between these packages <lfam>apteryx: I noticed that commit 26c0ff98cf4 (the recent Git update) includes a change to bcc that wasn't in the submitted patch nor mentioned in the commit message. Is it an oversight, or is it intentional? <juli>Quick reminder for those not reading guix-devel: don't cuss at people about their work. That's rude. Thanks for your attention. <dariqq>is there a problem with substitutes? I am unable to reconfigure my system for a couple of days since building the kernel takes forever on my hardware? <cbaines>things aren't great, the bordeaux build farm is still working through the large number of builds from the changes pushed to master a couple of days ago <cbaines>I haven't quite worked out what the biggest changes were, but subversion was updated which is ~850 affected packages at least <cbaines>which reminds me, given those changes on master, we probably need to rebase core-updates <cbaines>is there any changes that should be included at the same time? <dariqq>cbaines: Is #70999 something for gnome-team, core-updates or somewhere else? (selfishly promoting my own issue/patch) <ngz>cbaines: "core-updates" rebuilds all TeX Live and its dependents, "tex-team" rebuilds also all TeX Live and its dependents. Would it make sense to rebase the latter on top of the former and let bordeaux build all this stuff just once? <ngz>(we're talking about 12k duplicated builds…) <cbaines>dariqq, that looks like something that can be included, could you retitle the issue to have [core-updates] at the start of the title? <cbaines>ngz, assuming the changes on tex-team aren't very risky/problomatic, I think it's worth considering just folding tex-team in to core-updates <ngz>cbaines: I don't expect much breakage from this branch (famous last words), but one way to be sure is to let this branch build for 1-2 days while core-updates is pending. Most packages TeX Live take a few seconds to build, so it should give a good estimation on the state of the branch. <fnat>Anyone using the unclutter Home service (it hides the mouse pointer when inactive)? I get an error "could not open display" in the logs and the pointer remains visible. My setuid sense tingle, could that be the reason, that the binary needs to be made setuid? <ieure>fnat, That stuff doesn't need suid. <ieure>Maybe it's an X11 client and you're in a Wayland ssession? <fnat>ieure: Hey, thanks. Hm, no, I'm under X but thanks for suggesting that. It sounds as this will need some debugging then. <cbaines>dariqq, oh, I see the bug is against guix rather than guix-patches as well. You could keep the bug and send the patch to guix-patches, or you can just change the package for the existing bug, up to you. <fnat>It seems likely that it's because of some misconfiguration on my side in terms of my DISPLAY env variable. I can reproduce the same error message (that I get from the Home service) from the command line, if I mess with that env variable - as expected. <fnat>I wonder if the service should be doing something more sophisticated to catch the correct env variable though. <dariqq>i've sent it as an issue at first and then later added the patch. I think it wold just be easier for me if i resend the patch <ieure>I'm not real sure what the problem is. The linked ticket makes it seem like it requires the :0.0 format for DISPLAY, and doesn't work with :0 -- IMO that is a bug in the program, both are valid DISPLAY formats, and the :x.y format is *very* uncommon -- it was part of the super early (for the olds like me: pre-Xinerama) multihead support. <fnat>Sorry, the link was a bit of a red herring. In my case unclutter works fine from the command line (where DISPLAY is set to :0) but it fails with the same error I get from the service if I set DISPLAY to something else. <fnat>This makes me think that the service runs unclutter with an unset or wrongly set DISPLAY var. <cbaines>ideally we don't want to keep changing core-updates so what I think I'll do is <cbaines>rebase core-updates, add in more things, then push it as wip-core-updates <cbaines>then if people have other changes they want to make in the next day or two, they can be made to wip-core-updates <cbaines>then once the build farms have caught up with master, we can push wip-core-updates as core-updates <ngz>cbaines: The risk to leave "wip-core-updates" completely open is that some problematic patches could require more fixing, even though the branch currently looks in a good shape (albeit on top of an old base commit). <cbaines>ngz, it is a risk, although hopefully we can just remove those changes if we notice they're more work than expected <cbaines>so there's already some stuff to fix <ehmry>cbaines: hey, I saw you are working the guile guix-daemon, do you have plans for replacing the working protocol after achieving backwards compatibility? <cbaines>nope, currently I'm only thinking about making something compatible <ehmry>I have my own thoughts about replacing the protocol for nix and it would be ideal if another protocol was something we could share <ehmry>I don't want to distract you but I'm considering trying to get funding for protocol work <ehmry>of course it depends on how badly nix explodes :( <oljenkins>Hi there, I am trying to package python bindings for raylib. When I run "guix package -f my-package.scm", it exits with error: 'File "raylib/build.py", line 107, in build_unix. raise Exception("ERROR: raylib not found by pkg-config. Please install pkg-config and Raylib.")'. pkg-config and raylib are both installed and listed as native input inside my-package.scm. The exception in line 107 in build.py is <oljenkins>raised when the function call "check_raylib_installed()" returns False. The function "check_raylib_installed" contains just one line, "return subprocess.run(['pkg-config', '--exists', 'raylib'], text=True, stdout=subprocess.PIPE).returncode == 0". Then I ckecked if pkg-config finds raylib by running 'pkg-config --exists raylib && echo "exists"', but it didn't, although raylib.pc is in PKG_CONFIG_PATH. <oljenkins>Does anybody know how to solve this problem? <oljenkins>I am new to guix and it's the first time I try to package a python module. <redacted>I'd like to reconfigure my system, but I don't want to rebuild librewolf until the substitutes are ready. Can I reconfigure without building packages? <ieure>redacted, Actually looks like LLVM/Clang updates may have broken librewolf, at least, my personal Cuirass box is failing to build it. <ieure>Oh, I think this actually OOM'd my box. <ieure>Yeah, that looks like what up. <redacted>forgot rolling back a pull was a thing I could do <dariqq>oljenkins: ithink raylib is pacakged incorrectly and is missing a dependency. The raylib.pc file specifies glfw which raylib does not propagate <oljenkins>dariqq: So, does that mean raylib depends on glfw, but glfw doesn't get installed during the installation of raylib? <dariqq>oljenkins: it does seem to get downloaded when installing raylib but not in a way that pkg-config can find it if you only add raylib to your package. As a workaround for your package would be to add glfw to your package <dariqq>but ideally this should be adressed by the raylib package <efraim>raylib does have glfw3 in Requires.private in its pkg-config file, so glfw probably should be propagated by raylib <redacted>I'm trying to set /etc/subuid and /etc/subgid for podman. Would those be configured with extra-special-files? <efraim>oljenkins or dariqq: would either of you like to send a patch? <oljenkins>dariqq: I just installed glfw manually via "guix install glfw" and now pkg-config finds raylib. <oljenkins>efraim: Sorry, I am a guix newbie. I don't know how to send a patch? <dariqq> i dont really feel comfortable writing a patch for a package i know nothing about <juli>ehmry: there was some prior work towards unifying and updating the protocol of Nix-like daemons. one of the https://tvl.fyi/ folks reached out about it a while back <juli>cbaines is the local authority on the Nix daemon; just wanted to alert you to this other work <redacted>If I want to create a service run as a user that has root dependencies (such as files in /etc that should be owned by root), how should I handle that? <redacted>It makes most sense for the service to be a Guix Home service, but I need some way to either provide the dependencies or notify the user when they're missing. <redacted>If anybody is using Docker rootless in Guix already, I'd like to know how you're doing it. <oljenkins>redacted: in my /etc/config.scm I added "docker" to the supplementary-groups list and (service docker-service-type) to services list <redacted>I'd read that adding your user to the "docker" group makes that account root equivalent, which is why I'd not done that. <ieure>I don't believe that's correct at all. <ieure>It lets you manipulate the Docker daemon, which has root privs; the same way as `guix build' as a user manipulates the Guix daemon, which has root privs. <lechner>Hi, is C.UTF-8 the standard system locale in Guix? <ieure>redacted, Okay, I see and understand the issue. <JetpackJackson>has anyone been able to package any go packages? trying to package hydroxide and arduino-cli and struggling lol