IRC channel logs
2025-03-09.log
back to list of logs
<onf>I'm interested in the Android wired tethering method. So thats like using your Android phone as a wifi adapter right? <onf>or just buy a supported wifi adapter I guess <onf>I already do carry paper notebooks as its reliability is still unmatched <ieure>onf, More or less, yeah. Phone connects to WiFi, but when tethered to your computer, it presents as a USB Ethernet device. <ieure>Sidesteps the whole firmware situation, and I think folks are more likely to have an Android phone than a USB Ethernet or supported WiFi adapter. <onf>I'm more interested in creating a collection of software that I can easily install on a machine reliably using guile to define something like an iso <wakyct>like a live usb disk sounds like <wakyct>would there be anything stopping a live Guix disk though? <onf>I mean, there should't be right? <jmes>I'm trying to build a derivation during home reconfiguration (to install a `program-file`). I see that the meta command ,build runs `evaluate/print-with-store`, but is there an exported proc that does something similar like (build-the-darn-thing (program-file ...))? <jmes>Also I could be taking the entirely wrong approach. I just want to get a gexp script into the store so that I can insert its path in some config files at reconfiguration-time. I'm open to any and all suggestions. <jmes>Right now I'm doing this, but I realized that it doesn't actually build the drv: <jmes>((compose derivation->output-path <jmes> (cut run-with-store (open-connection) <>) <jmes> (program-file name gexp)) <anemofilia>Looks an XY problem, what are you really wanting to achieve? <jmes>anemofilia: I want to have some guile scripts built/put in the store so that I can refer to them in some dotfiles. I also want this process to be easy (so that means not making full-on packages). And I don't need the script in the user's profile (I only need to know where it is during reconfiguration). <anemofilia>If these files are only used inside your home, I would use the home-files-service-type for that <anemofilia>(service home-files-service-type `((".local/bin/script-name" (program-file ...)) ...)) <jmes>That would work. Then I would need to install to .local/bin and adjust $PATH <anemofilia>The same can be achieved with home-dotfiles-service-type <jmes>anemofilia: Thanks, installing to .local/bin worked fine. Now I'm just figuring out the guix-friendly way to set PATH <anemofilia> (simple-service 'home-shell-environment-variables <jmes>Ah, that's what I had tried but I remembered I need to log in again for it to take effect. <jmes>Well, that works. Thanks for the help <eikcaz>I want the location of a home-files-service file to depend on the value of XDG_STATE_HOME. Is that possible? <anemofilia>eikcaz: afaik the field that specifies the file location doesn't do any shell environment variable expansion. Also it expect the path to be relative to the home <anemofilia>You can use getenv, string-drop and string-append to achive something like that, but then you'd have to reconfigure every time you update that variable <eikcaz>hmm. The docs on home-xdg-configuration-files-service-type claims it puts things in XDG_CONFIG_HOME, but I see it's actually hard-coded to ".config"... <eikcaz>I guess that's fine: I'll just not support that use case :3 <anemofilia>Yeah, I got disappointed about that when I saw it too <quezt>> Has there been discussions about adding a nix flake equivalent to guix? <quezt>ACTION says uhm... let me not quote... <quezt>QA branches links appear to error. <apteryx>oops, recent mumi changes appear to break 'mumi current', perhaps other API <apteryx>mumi current 76572 -> GraphQL query failed with non-2xx status code: #<<response> version: (1 . 1) code: 500 reason-phrase: "Internal Server Error" [...] <apteryx`>I suppose I need to keep my local mumi in sync with the one running on berlin; I'll update and retry <PotentialUser-12>Hi, I'm trying to package zig-zls-0.14, but in Zig 0.14 they changed how build.zig.zon works, so packages that work for 0.14 won't work for 0.14 and vice versa. An example of this issue is zig-known-folders <PotentialUser-12>Here are the links to the different build.zig.zon due to the release of Zig 0.14 <apteryx`>hako: hi! I tInk in v3 of bug#73494 we can't import (guix diagnostics) or (guix i18n) inside the gex, as that ends up importing too much <apteryx`>(it's not intended to be used on the build side) <apteryx`>most things intended to be used on the build side are namespaced as such (guix build ...) <ennoausberlin>Hi all, I wonder to what degree it is possible to recreate a config.scm for an existing Guix System. Current users and file systems can be found, herd services as well, X config maybe, what else is missing? <dissoc`>ennoausberlin: what do you mean by existing system? <ennoausberlin>Guix SD. I am really good at losing my config.scm especially on Pinebook Pro. I do a lot of tweaks to the standard config and lose the config afterwards. Don't ask me how. <lilyp>ennoausberlin: `guix system describe` should give you an interned copy of the config file <ennoausberlin>So if I at some point want to run reconfigure I always struggle to find where the config was coming from. It usually starts with Manjaro on EMMC and I write to SD card from there, but I do distro hopping on EMMC and when there is no backup ... <ennoausberlin>lilyp: I do not see the config file via guix system describe. Just a link to the systems profile. Maybe it will appear only after first reconfigure there <ekaitz>i have found that debian builds wxwidgets without egl support, should we do the same? <ekaitz>kicad can't use wxwidgets with egl in x11 <ekaitz>and we have also prusaslicer built with a custom wxwidgets that disables egl...? <ekaitz>i don't have wayland, but I managed to update kicad 7->9, if someone that uses wayland wants to test, please let me know <ekaitz>csantosb: yep, but don't worry, i'll manage <csantosb>Still fighting with this kcad package, I see <ekaitz>csantosb: but i found the issue! <ekaitz>we have wxwidgets with EGL support but Glew doesn't support EGL so everything dies <ekaitz>i compiled wxwidgets without EGL and Kicad just works perfectly <PotentialUser-13>Hello. I have a shepherd service that is failing to start. How can I find more information on what is wrong with it? <csantosb>ekaitz: great news ! kicad is a great piece of software, it deserves we deliver a recent release <csantosb>Related to that, and more generally: when we package something, it's worth communicating about it <jA_cOp>PotentialUser-13: you can have a look at /var/log/messages while starting the service, to see if it outputs anything there before exiting <jA_cOp>you could also run `herd detailed-status` to see the service's full command and try to run it yourself on the command line, but it may be a little challenging to match the environment for a like-for-like test <PotentialUser-13>jA_cOp Thank you. Sadly, nothing is logged to /var/log/messages. It just says the service is currently disabled. <jA_cOp>PotentialUser-13: when a shepherd service "fails too fast", it gets disabled and you have to enable it again before you can start it. The details of this you can find in the shepherd manual, but to start it again you have to `herd enable bluetooth` and then `herd start bluetooth` <PotentialUser-13>One more thing: guix system reconfigure gives me the following message I do not understand: <PotentialUser-13>"WARNING: (guile-user): imported module (guix build utils) overrides core binding `delete'" <jA_cOp>Someone more knowledgeable can probably clarify, but I assumed that warning is because Guile has a `delete` function in the standard library, but that Guix module introduces its own `delete` (I think the one used in modify-phases?) which shadows the standard function <quezt>does guix pull upgrade automatically? often, it seems guix package -u has nothing to do after but reconfigure does. <quezt>ACTION better install an XMPP CLI client with omemo support... <PotentialUser-13>jA_cOp I am way too noob to do anything fancy with my system configuration. It is quite small and simple. Thus, I am surprised that noone else saw and addressed the warning. <PotentialUser-13>Enabling the service before starting it seems to produce output on /var/log/messages! <ngz>quezt: maybe you have many system packages a few user ones. Guix pull doesn’t upgrade automatically, btw. <quezt>ngz, yes. the service types do have many. emacs-guix showed as much. <quezt>I have mate. it was working fine until a reconfigure. rollback works and profile comparisons showed only gsconnect as changing. tracking changes with eza also yields zilch. what is recommended for such a bisection? <quezt>lxqt launches. openbox does not. gnome crashes before getting to desktop with a popup. am going to reboot: session not appearing at all. <apteryx>hako: I think I've found why the jami-dbus-session service hangs with the /var/run -> /run symlink <apteryx>it's because by default dbus creates its pid file and socket under /var/run <apteryx>we'd have to share the symlink as well in the container <apteryx>but I'm fixing it where it needs to be fixed: dbus <h4>Okay I give up, after weeks-months of searching. How do I run hardware acceleration on Gnome WM/DE? It was configured right and since an update, nothing. No I don't want to rollback, I want the configuration necessary for Mutter to run in GPU <h4>h4: Well, it was. Now it's software rendering <h4>apteryx: Gnome settings panel, and yeah Gnome logs <hako>Is mesa installed to a profile? <h4>hako: Afaik the used profile do have Mesa installed, but maybe a command to verify? <h4>But fr there is not only one mesa... name: mesa name: mesa-utils name: rust-osmesa-sys name: mesa-opencl-icd name: mesa-opencl name: mesa-headers name: llvm-for-mesa <apteryx>h4 I see this in my /var/lib/gdm/greeter.log: libmutter-Message: 21:09:16.578: Boot VGA GPU /dev/dri/card0 selected as primary <apteryx>in my case it seems to be accelerated fine <h4>$ ls -a /var/lib/gdm/ ./ ../ .cache/ .config/ .local/ <h4>$ grep VGA /home/$USER/.cache/gdm/session.log libmutter-Message: 13:43:50.745: Boot VGA GPU /dev/dri/card0 selected as primary <apteryx>the above line looks fine? what makes you think there's no GPU acceleration? <quezt>saw something about GPU arbiter missing in my logs. So only one GPU at a time. <h4>Well graphical lag and what say Gnome settings panel <apteryx>where exactly in gnome setting, I couldn't see that <quezt>old and Ryzen 3 machine. Vegas and topaz. <h4>$ grep accel /home/bob/.cache/gdm/session.log libmutter-Message: 13:43:50.745: Failed to initialize accelerated iGPU/dGPU framebuffer sharing: Not hardware accelerated libmutter-Message: 13:43:50.890: Disabling DMA buffer screen sharing (not hardware accelerated) <quezt>old amd Ryzen 3 machine. Vegas and topaz. <apteryx>h4: is this an old machine? I think some legacy drivers in Mesa were removed <h4>Nope, new machine, idk like 2 years <apteryx>hm. And search engines do not show useful references having this kind of issue? <quezt>think igpu requires additional thing to mesa for accel. libva? <h4>Well search engines talk about getting Mesa, lol <apteryx>libva is for decoding/encoding, as far as I know, not 3D acceleration like opengl. <quezt>apteryx try archwiki for intel <h4>I was stunned that there is nothing precise about what should be done. And worse, package description on Guix are really generic, sometimes copied between them and don't really explain for what it's necessary. And obviously no part about that on the manual <apteryx>there shouldn't be any need to install stuff to get basic acceleration working <apteryx>at least for GPU supported by free drivers <apteryx>perhaps it needs nonfree firmware blobs like AMD ones nowadays? <h4>$ grep kms /home/$USER/.cache/gdm/session.log kmsro: driver missing <apteryx>like attempted to load firmware and failed or something <quezt>ACTION wonders is that what I used to use? <h4>$ grep --only-matching *modeset* /proc/cmdline\ni915.modeset=1 <df>am I right in thinking that after guix package creates a new generation, you will *always* get the "hint: Consider setting the necessary environment variables" if a var has been added that's not in your current process's env, even if you're set up so that <profile>/etc/profile will run on login? <h4>$ sudo dmesg | grep --ignore-case fail [ 2.910439] intel-ipu6 0000:00:05.0: Direct firmware load for intel/ipu/ipu6ep_fw.bin failed with error -2 [ 2.910443] intel-ipu6 0000:00:05.0: error -ENOENT: Requesting signed firmware intel/ipu/ipu6ep_fw.bin failed [ 2.910478] intel-ipu6 0000:00:05.0: probe with driver intel-ipu6 failed with error -2 [ 2.969970] platform regulatory.0: Direct firmware <apteryx>df: yes, because environment variables can't redefined by the child process <df>I mean, I used to think it was a warning that your system was incorrectedly configured, but possibly it's just telling you that a var has been added so you might want to rerun the profile <apteryx>if you launch a new shell you'll be fine <quezt>man, everytime I encounter support issues where there were no problems before I blame Microsoft like Christians blame the devil... <apteryx>not related to your problem, I reckon <h4>I really fail to get a log line that explains why Gnome judge that there is not hardware acceleration. I don't see anything but directly look at Gnome code to see what he looks for <apteryx>and does hardware acceleration works in other contexts? e.g. glxgears, etc. <quezt>does one have to declare Wayland in system packages for it to work? Only wayland-scanner is present through all the trials here. <h4>GLXGears only want to use LLVMPipe <h4>Otherwise glx: failed to create drisw screen Error: glXCreateContext failed <apteryx>h4: I'm not sure why this happens for you :-/. In my experience intel GPU just work (tm) with accelerated graphics <apteryx>you'll want to dig into the mesa project to see how to debug this <h4>Yeah, was the case for me aswell... Pretty sure my scm have a problem, but Guix manual is really not helping at figuring out what should be there <apteryx>I think there are tools like glxinfo that could perhaps print something useful <h4>I don't even know how to know if anything tries to use Mesa or not <apteryx>as I wrote earlier, this kind of thing should just work, since every application links to mesa's GL.so, with driver support in the kernel built for most GPUs <apteryx>the white elephant in the room is that modern GPUs often want to load nonfree firmware files (*cough* AMD) <h4>So that so is supposed to be used <h4>Yeah, maybe the problem is over there, difficult to know really <apteryx>maybe boot in a live distro like ubuntu, that should include everyhing under the sun whatever the license, and see how it works there, and what it's using <h4>At least for nVidia there is explanations here and there, but Intel is assumed to be supported as is, so no explanation nowhere <h4>Spinning an Ubuntu won't help, like yeah he will use everything needed, but I won't be able to determine what lacks in my system <h4>Not same package name and even then, won't be able to know which one <apteryx>you can inspect the drivers loaded, firmare loaded in dmesg, etc. <h4>Maybe if I would be able to get in touch with those graphic package maintainer for Guix, he would be able to explain me what does what, what is needed, and so <h4>Or I need someone like who should know how Mutter check hardware acceleration <h4>Heck, even at least someone that can just *explain* what are all intel/mesa/vulkan packages on Guix, what they do precisely <apteryx>I'd think you'd get better help from the mesa3d project, stating to them you are using linux-libre hence no firmware drivers, and exacty which intel chip you are attempting to use <apteryx>they hang out in #dri-devel on the OFTC irc server <h4>Intel is supposed (since long) to rely only on libre driver, if now it's not the case anymore, then it's really difficult to figure out <apteryx>h4: we don't have that many mesa variants <apteryx>there's like an opencl variant as well as an mesa-opencl-icd variant. <apteryx>the drivers built by default are the defaults of mesa: "-Dgallium-drivers=auto" <h4>Yeah but even those one I don't get it <apteryx>h4 which processor exactly do you use? <apteryx>apparently this comes with the Intel Iris Xe Graphics GPU solution <h4>I mean, the CPU coming with that "solution" what it implies with Mutter using software acceleration? <apteryx>it seems it will be either using the xe or i965 kernel drivers <apteryx>and xe appears to want to use something called GuC which require non-free firmware <h4>I tested both i915 and xe and the problem happens in both <apteryx>what does 'lspci -nn | grep VGA' say? <h4>00:02.0 VGA compatible controller [0300]: Intel Corporation Alder Lake-UP4 GT2 [Iris Xe Graphics] [8086:46aa] (rev 0c) <h4>As I switched to xe like few minutes ago to test if it changes anything <h4>But since months, the problem is i915 based <apteryx>you are using the default wayland gnome session, right? <h4>wdym, what are non default ones? <h4>Idk precisely what it's supposed to mean but I'm running WayLand right now <apteryx>this suggests you may be needing non-free firmware to have recent intel gpu run <h4>Wut, but it was running fine few updates ago. which part of the repo specify that? The readme don't states much <apteryx>ah, sorry, I had forgotten that this was a regression... then it'd point to something that changed in mesa <apteryx>that won't be fun/cheap to bisect, if you pursue that <apteryx>sorry, I'm tired and my suggestions are not that useful, ha! I'll get some rest. Good luck! <h4>Thanks for your help! <h4>Maybe it's not a regression, but rather me that have misconfigured my scm, but can't figure out where <apteryx>h4: I doubt so; we just updated GNOME from 44 to 46 a few days ago <jlicht>is anyone having any luck getting python-numba to work on their machine? <h4>Like I said it's a problem that last since weeks/months, so not really a push from few days ago <h4>I don't even have the data quota to download what was pushed recently lol <apteryx>git log --grep='gnu: mesa: Update' will show you when it was last touched <apteryx>last update was to 24.3.2 3 months ago <jlicht>apteryx: Yeah, but like ludo mentioned, it seems that this is due to platform differences. Disabling all tests seems to be a bad idea though I guess :D <h4>I would have to clone locally beforehand or locate the system git local clone <h4>And guix git log don't work neither <apteryx>h4 yeah I'm talking a regular git clone <h4>Ah yeah, don't have the data quota lol <h4>But I believe you on that part <df>putting stuff directly in /etc feels a bit un-guixy <h4>df: You don't put your system configuration file there? <df>nah, I have it in a git repo in my home dir <df>I'm about to add channels.scm to said repo and symlink to it, but currently it's duplicated for both my root and normal users <hako>guix-configuration now has a channels field <df>ah right, can add it there then <df>it makes sense for it to go along with the substitutes servers the channels use <Rutherther>df: why are you using root's guix anyway? are you on foreign distro and pointing guix-daemon to root's guix? because if not, I don't really see what other uses it has <df>Rutherther: er, not sure I follow - I use it for guix system reconfigure <Rutherther>how are you reconfiguring? most users just use sudo <df>I suppose there's no good reason why <df>just seemed like the natural thing to do <Rutherther>most users don't use -i, I suppose that yeah, with it you are using root's guix channels <jA_cOp>this set me back a lot when I first started, it's not obvious to me which part of the environment affects the Guix CLI - is it the user ID? $HOME? $USER? Other environment variables? The difference between using guix with just sudo from a user, or with a root shell, or in a chroot etc. is confusing <jA_cOp>It would have been nice if it was documented as part of, or linked from, the docs on the manual installation process <Rutherther>jA_cOp: no, guix executable is taken from PATH, that is the only env var that decides which guix instance is used <df>jA_cOp: one of the things that confused me when I started is that guix itself (as fetched by guix pull) is in a separate profile to the rest of your user's packages <df>specifically, guix is in ~/.config/guix/current and everything else is in ~/.guix-profile <df>so I have been using /root/.config/guix/current for my system-related activities but as Rutherther points out that is unnecessary <df>(I am a total noob myself though so hopefully someone more knowledgeable will correct me if necessary) <ngz>qa.guix.gnu.org/patches seems unavailable. <cbaines>yeah, there seems to be some issue talking to issues.guix.gnu.org <cbaines>I don't know if it's an issue with the queries from QA or not <ngz>At least it’s not me ;' <ieure>Is there some workflow to apply patches with debbugs that preserves the commit message & author? <ieure>`mumi am' is failing because the mumi server is 500ing, git.ga.guix.gnu.org doesn't have a branch for the patch, so, I can't apply any patches. <ieure>Unless there's some other equivalent workflow. <Rutherther>doesn't mumi am just git am the patches parsed out of the e-mail? <ieure>Rutherther, It uses GraphQL to fetch the patches from a mumi server instance, and the one for Guix is broken. <Rutherther>yes, I get that. What I am saying is that if you just download the patches and git am them, it will do the same thing as mumi am in the end <Kimapr>Is anyone else experiencing problems with the wine package? namely that it doesn't run at all <Rutherther>Kimapr: you're probably using the wine package which is 32-bit wine, you should probably be using wine64 <Kimapr>seems something to do with dynamic linking (error is just "No such file or directory" when the executable clearly exists) <Rutherther>yes, it uses 32 bit linker that doesn't exist when compiled against 64bit <Kimapr>Was it always broken? i feel like it used to work before <Rutherther>I can't say that. Well it oesn't exist, because glibc for x86_64 doesn't compile it, only i686-linux does. Is there a reason you don't want to use wine64? <ngz>ieure: I don’t even know how to close a bug with Debbugs. `C' and "close" doesn’t seem to have any effect. <Kimapr>can wine64 run 32-bit applications? <ieure>ngz, That closes bugs for me. <ieure>ngz, Maybe your debbugs email configuration isn't set up correctly? <ieure>ngz, Not excusing anything here, just trying to be helpful. Dealing with patches should not be remotely so complicated as it is. <ngz>ieure: Where should I look for configuring this (you are allowed to kindly point me to the fine manual)? <Rutherther>ngz: did you send your e-mail to control e-mail at debbugs.gnu.org? <ieure>ngz, I'm not sure, probably M-x customize-group RET debbugs RET. The first time I sent an email, it asked me what method to use, that's what I'd be looking at. <ngz>ieure: OK. Thanks. However, after a cursory look, I don’t see anything obvious. I’ll keep sending manually stuff to NNN-close@… instead <ngz>ieure: BTW, if you are motivated enough, you may want to look at issues 74135, 74136 and 74137, which are kinda stuck Emacs packages and in dire need of an "external" POV. <makx>mhm, so I think the recent(?) gnome update broke the ssh-agent integration <ieure>ngz, I can look, but can't apply anything right now <ngz>Good ole copy and paste! :) <ngz>ieure: Anyway, I can apply the patches. It’s a social failure there, not a technical one. <ieure>ngz, The patches need work, I'll chime in. <ngz>ieure: I wish you better success. <lilyp>makx: that's a gnome 46 thing sadly; you need to run gcr-ssh-agent on your own <lilyp>maybe someone should write a home service for that <makx>lilyp: is gcr-ssh-agent available on guix? <makx>I see it is, itś just not in the path <dariqq>lilyp: the ssh agent can (currently) be reenabled with a configure-flag (--enable-ssh-agent) <lqd58>Hello, everyone. I am having an issue with the guix installer. I'm building and using a slightly modified version of the installer. I'm doing my installation manually. I create my partitions, mount on `/mnt`, `/mnt/boot/efi` and `/mnt/home` - and then I run `herd start cow-store /mnt`and my `guix system init` command. It runs fine but once the <lqd58>installation is complete and I run `reboot`, I get a bunch of errors in the tty about not being able to delete stuff until it eventually just turns off. When I boot the new system I get the 'recovering journal' messages. Any ideas? I'm new to this so if I'm missing something I apologize. <lqd58>My system config is in the same repo (orchard/system/abraham.scm). If this is the wrong place to ask for help, please let me know. <ieure>lqd58, Not sure about your problem, but you're getting "recovering journal" because one or more filesystems aren't being cleanly unmounted before the system reboots. <lqd58>That's what I was assuming. Do I have to manually unmount all my system partitions before I reboot? The manual doesn't say anything about it, so I didn't do it. <lqd58>I'm thinking it has to do with the `cow-store` service somehow - several of the errors I see before the reboot seem to be related to the directories it uses. If I try to stop it with `herd stop cow-store` after the installation, I get an error. <ieure>I'm not sure, I haven't used the manual install much. <Rutherther>lqd58: could you capture the errors you get upon boot and send them? <ieure>I'd think this stuff should get handled automatically. <Rutherther>there is no way it has something to do with cow-store. Cow store is just to make sure stuff going to /gnu/store doesn't fill up your ram <Rutherther>or.. are there even errors when you boot or is the journal successfully recovered and you boot? <ieure>Is `reboot --kexec' working for others? It's worked a couple times for me, but mostly just hangs my machine. <lqd58>Rutherther: The errors only show up when I run the `reboot` command on the installation ISO after running `guix system init`. They show up *before* the system reboots. When I boot into the new system, the journal recovers successfully and it boots. I'm trying to figure out what's causing the errors, though. I don't want anything in my new system's <lqd58>I'm on the new system right now. It was behaving a little strangely when it first booted, so I had to run `guix pull` and `sudo guix system reconfigure` before things seemed to behave normally. <lilyp>ieure: probably depends on your available ram, but it does work for me <lqd58>ieure: In the past it's worked, albeit very slowly and with strange warnings on boot. <lqd58>Rutherther: I will attempt the installation again to capture these errors. I'll run `guix pull` and generate a new ISO first. <dariqq>i just investigated my "recovering journal" warnings and it was related to my swapfile <Rutherther>lqd58: it's definitely better practice to unmount yourself the disks you mounted yourself. Especially to make sure there is really nothing writing to them that can cause corruption. That being said, it's usually fine even without unmounting manually as long as there is no program killed that were writing to the disk <lqd58>Rutherther: That's good to know - I'm still familiarizing myself with all of the best practices. Should I `herd stop cow-store` before I unmount the disks, or should it be fine to leave it running before I unmount? <Rutherther>lqd58: also imo, if you just want to be sure the store is not corrupted, run verification through the guix gc command, I wouldn't be too much commited to investigating the installation metthod for corruptions, at least if you aren't doing many installations a week. The thing is that it might end up not reproducible, because for example something was running in the background and you haven't noticed. <ieure>lilyp, My machines all have ludicrous amounts of ram. Just tried this on a 32gb machine and it didn't work. <Rutherther>lqd58: you can try without it, but it will not unmount probably. Cow store makes overlayfs with backing directory on the mounted disk. So the disk is used as long as cow store is running <lilyp>I've only ever had it fail when stressing my ram and swap <Rutherther>lqd58: executing umount should generally be safe, it will just abort if something is using the disk, even if it's just a folder open in shell <dariqq>ieure: what do you mean by hang? i only suffer from #76554 (type pw blind and then manually wake up my monitor by adjusting brighness) <lqd58>Rutherther: Ah, okay. I *do* actually plan to install Guix System on several different devices over a period of time. I'll spare you the context as to why, but I would like to understand the installation process better since I will be doing it a lot. I will run the verification after the new install and report back here. I have a new ISO generating <lqd58>from the latest Guix right now. <lqd58>Also, quick question: Should I be running `guix pull` and `guix system reconfigure` as root? Or should I be running it as a user? I've been trying to wrap my head around keeping `guix` up-to-date across multiple users, along with `guix system`. How do y'all manage `guix` versions? <lilyp>`guix pull` as user, `guix system` as user mostly; only `reconfigure` as root <lilyp>imho we do need better ux to ask for permissions <lqd58>Yeah. I can't tell you how many times I've run `guix system reconfigure` only realize that I forgot to use `sudo`... and then I have to wait for guix to do everything again, this time under the root user's cache. <Rutherther>if you run just sudo guix system reconfigure you shouldn't have to wait for much. The build has already succeeded from before, only the activation itself and that is usually quick <lqd58>For whatever reason, it downloads many of the same packages a second time when I run it again with `sudo`. I'm sure I did something wrong, though. I've been screwing around and messing things up with guix a lot. <Rutherther>(if so, that would lead to that behavior and I would recommend not using that) <lqd58>Rutherther: I only ever use `-L .` as a flag. Bear with me - What is the `-i` flag? I don't see it in the `--help` menu. <guix-noob>hi all...i am getting error "guix pull: error: Git error: unexpected http status code: 502" when trying a guix pull ... <ieure>guix-noob, Probably Savannah is hosemode again. <Rutherther>are you still getting that? because savannah works for me <redacted>I'm having a hard time packaging something that uses CMake and clang. <redacted>Seems like it's not finding the C standard libraries. <redacted>I've kept the failing build directory and checked the environment variables. <redacted>C_INCLUDE_PATH has glibc in it, so I'm a little stumped. <redacted>It's reporting stuff like malloc.h missing. <redacted>Looks like CMake's tests for the system libraries are failing to find bits/c++config.h <redacted>Which guix locate tells me is in the gcc package <redacted>Which appears to be a deprecated package? Confusion <redacted>interesting, bits/c++config.h is in /include/c++/x86_64-unknown-linux-gnu/, not /include/c++ <PotentialUser-12>How do I verify that my email was received by the mailing list? I emailed help-guix@gnu.org about an hour ago, and it hasn't appeared in the archives. <lfam>redacted: The 'gcc' package is not really intended to be "used". Instead the the gcc-toolchain packages are what people are supposed to use <coyotes4ys>i am looking for the quickest easiest way to cli bluetooth headphones <lfam>Probably nobody that read your messages yet knows how to do that <redacted>There's a bluetooth service type. I think that also gives you the bluetoothctl command. <coyotes4ys>i can see how to herd start bluetooth, but no way to add the service in the first place <redacted>Ah, you're using a foreign system, right? You've installed guix in another linux distro? <redacted>You'd add it to the services list of your system configuration. <redacted>I'm checking the manual to figure out where your system configuration would have been mentioned during install. <redacted>I think it tells you to put your system config in /etc somewhere if I recall right <redacted>You can copy that to your home directory or wherever you want. That path isn't special. <coyotes4ys>curiosity question, how is that path not special? how can the system find the file? <redacted>You use that file to tell the system how to set everything up, but it doesn't read the file after that. <redacted>The installation instructions told you to put it there just so you'd have a copy of your current configuration to modify after you booted into your new system. <redacted>That looks like it. Does your configuration already have a services list? <coyotes4ys>i did herd status and it spit out bunches of service names <redacted>Oh, sorry. I mean config.scm should have a list. Let me see if I can find the relevant manual page to illustrate <redacted>Hm, the manual page on services has some examples I think might be confusing. <redacted>You'll need some scheme knowledge if you want to configure your system in the long run, but I want to try getting your bluetooth set up at least <coyotes4ys>i just added the two service lines listed in the answer on the se page i linked. is that right? <redacted>You should only need (service bluetooth-service-type), I think <graywolf>lilyp: Hi! Looking at the manifest, comment in the file still says `...packages built using the cargo-build-system.'. Does not affect the function, so just fyi. <redacted>Then sudo guix system reconfigure config.scm should update your system to match the configuration in config.scm <coyotes4ys>hmm gnu/services/base.scm:772:37: error: host name 'propeller 2' contains invalid characters