IRC channel logs
2026-07-19.log
back to list of logs
<rgarcia>hi! I did: guix install python-mido, but then I run python3 and do import mido and it cannot load the module, as if it weren't installed. How does it work? <ieure>rgarcia, Guix System or foreign distro? <ieure>Huh, I would expect that to work, I'm not sure. <rgarcia>I also tried guix shell python-mido -- python3, within I tried import mido, same result <rgarcia>also in the python shell I did import sys and examined sys.path and that list does not contain the path to python-mido <ieure>`guix shell python python-mido -- python3' works for me. <ieure>You need both packages in the same profile. <ieure>Where do you have the python package installed? <rgarcia>well, that's one way. But say I wanted to have it in my profile... well, I haven't tried re-logging <ieure>If I run `guix shell python -- guix shell python-mido -- python3', that doesn't work. So if you have python installed in your system profile, but python-mido installed in your per-user profile, that would explain the behavior you're observing. <ieure>Or it could be a log out/in situation. <rgarcia>I see. I installed python in my profile. I should try the log out-in <ieure>Yeah, so I think what happens here is $GUIX_PYTHONPATH is set to your old profile generation without python-mido. Log out/in uses the new profile generation with mido. <rgarcia>ah, nice to learn about that environment variable <rgarcia>maybe there's a way to ask emacs to load env variables of the most recent generation? <ieure>rgarcia, Yes, emacs-guix has this, guix-set-current-profile. <ieure>I'm not sure how well it works, seems unlikely that it reloads new versions of anything loaded into the session, but ought to work for new stuff. <rgarcia>I did guix-set-current-profile, was presented with options from /var/guix/profiles... selected the one with the highest number. Then tried to import mido but nah, failed <ieure>You'd have to restart any shells or processes Emacs started. <rgarcia>ah well, don't wanna log out. I'll just use an inferior python thru guix shell <ieure>Yeah, pretty easy to give the python command as a `guix shell' that spawns it. <ieure>I use `guix shell' to run stuff all the time. Keep the actual profile light-ish, and run stuff in a subshell as needed. <rgarcia>yes! I thought it was like a python virtual environment but, well, better, for anything! <rgarcia>so... do people use scheme to develop GUIs? <ieure>Sure, but you might want to ask in #guile or #scheme about the best way to do that. <graywolf>Hello Guix :) Do I need to put (ice-9 ..) modules into #:imported-modules, or does it suffice to put it into #:modules? <graywolf>is it just me or is codeberg pretty much unusable currently? <sham1>It's not just you. Codeberg is having some trouble <nomike>Does someone in here run Guix on an aarch64 system? <nomike>Someone reported that the "openscad" package does not properly build on that architecture due to failing tests. <nomike>And I want to have a look at it as I'm very familiar with OpenSCAD, but I don't have a system with that architecture. <ieure>Kinda, I have it on a raspi, but it's a foreign package manager on top of Debian, not Guix System. <nomike>All i need is someone who can run `guix build openscad --keep-failed`. It should fail at the end and there should be a ctest report in HTML and I just need that file. <nomike>It should say something like "report saved:\n /home/nomike/coding/pythonscad/build/Testing/Temporary/__amd-radeon-graphics-_radeonsi,_bvsi_report.html" at the end, and that's the file I need. <ieure>nomike, I will see what I can do, but I have to pull first, and this is a very slow process. <bdunahu>would you be able to get that by using qemu-binfmt-service-type and then cross compiling for aarch64-linux? <pathera>hey im having an issue with a new install from the config.scm i reused an old config so it shouldnt have issues but its pulling an issue with librewolf "error: librewolf-compare-paths.patch: patch not found" i could just remove librewolf from the config and reinstall it after but is there an easier workaround for this? <ieure>bdunahu, Using qemu-binfmt-service-type is different from cross-compiling. It's an option, but it's very slow on x86 hardware. <nomike>bdunahu, I'm not familiar with Guix yet I'm afraid. But I'm also running Guix foreign on Ubuntu, so I'm not sure if that's even possible. I was considering setting up a VM with libvirt, but I thought it's probably better to ask here first and keep this as second option. <ieure>pathera, Hummmm, librewolf should not be broken, I updated it yesterday. Let me see if I screwed something up. <ieure>nomike, I'm building openscad, I pulled out some faster ARM hardware than the Pi. <bdunahu>ieure: oh would what I said also build on aarch64, not just compile for it? <bdunahu>that's not really what this (info "(guix) Submitting Patches") suggests to me <ieure>bdunahu, I don't understand the distinction you're drawing between "build" and "compile." <pathera>ieure: thanks its just not pulling that patch file though i installed it through the package manager last night so that is still working i think <ieure>bdunahu, Cross compiling is using a compiler which runs on (for example) amd64, but produces binaries for aarch64. <bdunahu>"build on" versus "compile for", but the info manual does say "build on" so this does not have anything to do with cross compiling <ieure>pathera, I see the patch in the Guix repo, it's listed in gnu/local.mk, none of that changed in the last few updates. <ieure>pathera, What guix commit are you on? <pathera>dont think id be any? im just trying to pull the package in my config file and it came up with that error. though i had no problem downloading it normally yesterday. ive currently just commented the line and its working since i can just install it after just thought it was of concern since it wont install that patch <ieure>nomike, The file you requested doesn't exist in the tree left by `guix build -K openscad'. If you like, I'll tar up the whole thing and send it to you via magic-wormhole. <ieure>pathera, There must be a Guix commit, `guix describe' should tell you what it is. The error you're seeing seems like a build failure, which means there's no substitute for the librewolf version in your current guix. The implication here is that you're on an old guix commit. <ieure>The patch isn't "installed," it's applied to the source tree during the build process. <ieure>pathera, I can't reproduce your failure on current master, commit b0a26a6d132bd069cfed275dd2dfeaab12f28843. There are librewolf substitutes. Please try `guix pull', then whatever you were doing that caused the failure. <ieure>pathera, If you can reproduce the failure, please open a ticket with the procedure to trigger the behavior and assign it to me. <jresich>what process serves guix substitutes on the substitute servers? i mean, is it nginx or some bespoke guile program <jresich>and if it is the former, could byte range download support be enabled? that would make it easier to download large substitutes from bad connections <sham1>jresich: I'd take a look at what `guix publish` does <jresich>i know guix build etc. doesn't support it, but curl does so I've been ssh'ing into a pubnix with byte range support, downloading big substitutes to there, and then curling them to my home network <sham1>guix publish does compression on-the-fly, so a range request might be a bit difficult, unless it was made so that when --cache is specified, it also allows for the ranges <sham1>FWIW, I don't see why we couldn't teach `guix publish` to support range requests. It would also allow for resuming partial downloads of substitutes <sham1>Hell, I think that it could make it possible for you to download a substitute from various substitute servers at the same time. Since we know the content hash, we know that we'll be getting chunks of the same substitute <jresich>when you put it that way, adding byte range support to subsitutes is proabbably an important stepping stone on the way to P2P substitutes <sham1>But yeah, apparently it uses the Guile HTTP server library thing, so that'd probably be the first place to look, whether that supports ranges and if so, how <sham1>Also it seems that this code is technically not doing HTTP right, because it support GET but it doesn't support HEAD <sham1>Maybe you should make a ticket out of this range thing, so that this could get to a more concrete stage <PotentialUser-63>Hello. This is not directly related to Guix, but I hope to find help here. I stupidly dd if=something.iso of=/dev/myhd and well I cannot boot anymore. Do you know how I could attempt to retrieve some of my data? I tried to boot a Debian USB, it finds the partitions, but installation fails at GRUB installation. <sham1>That seems like a very difficult situation since you have overwriten your partition table etc. Your best best would probably be some kind of data forensics recovery tool dodad <nomike>ieure, could you maybe send me a file-listing of the build folder fitst? That should be smaller and I can then tell you which files I would need. And maybe the console output of the build as well. <PotentialUser-63>sham1: yes, this is bad. I booted on System Rescue, I’m trying testdisk commands at random… <stephen0>PotentialUser-63: did you realie the error and kill the command or did it over-write the full 4GB? <stephen0>And do you recall if you maybe were lucky and had a boot and a swap parition on the disk before your root? <stephen0>Do you know what your partition table layout looked like before? <stephen0>Here's the deal: you lost 4GB of data at the beginning of your disk. If any of your partitions started *after* that 4g, you could use something like foremost, but it will suck because you'll have mountains of data to sift through. <stephen0>Sorry, mispoke, if any of the partitions started after the 4G you can still mount those and get your data. If the partition was before that 4G then you have to carve. <stephen0>But what I do know is that the linux mount command can take an optional offset argument. <stephen0>I can give you a snippet of bash script, I just have to find a pastebin service to use. <PotentialUser-63>Another problem is that I cannot manage to mount my external HDD on System Rescue for receiving files I might save <stephen0>oh, wait, were any of your partitions encrypted? <stephen0>Assuming they are *not* then edit that script and set DEAD_DISK to whatever device you nuked. <stephen0>As it runs it will spit out offsets and sample commands and a list of the files on what it managed to mount. <stephen0>If you do have your home and root on separate parititions, you should be able to find at least one of them. <stephen0>no internet connection on the system that's broken? <stephen0>oh, I didn't add an exit case, either... so it would eventually go into a tight loop and not stop, ideally you kill it after it spits out one or more commands. <ieure>PotentialUser-63, If you dd'd to your HDD/SSD, you would have overwritten the partition table and filesystem headers... If you dd'd just to a partition, the partition table will be there, but the filesystem will be corrupt. <ieure>PotentialUser-63, Absolute first thing you need to do is image the disk in its current state, and store the image on some other media. Then try to recover what you can from the image. <ieure>PotentialUser-63, Once you have the master image, make a copy of it to work on. So if things go wrong, you don't have to image the disk again. <ieure>PotentialUser-63, I would start by fsck'ing the filesystem and see if it can repair anything at all. If that fails, try binwalk to recover files from the image. <ieure>PotentialUser-63, You have probably destroyed all the data on the disk, so recovering even a single file is a success. <ieure>Also, recommend using `lsblk' to make sure the disks are what you think they are... And using paths like /dev/disk/by-id/... makes it much harder to write to the wrong one than using /dev/sda /dev/sdb etc. <sham1>And this is also why we know `dd` as "disk destroyer" <PotentialUser-63>Well, I think I’m going to give up. I cannot make anything good out of the tools I’m trying <sham1>This is also why ventoy is a good thing, because you can just copy your ISOs into thumbdrives that have Ventoy in them, so there's no risk <sham1>Also, this is a good teachable moment about the importance of backups <PotentialUser-63>sham1: this is actually the fun part. I had backup setup every 2 hours, but they stopped working one week ago and I didn’t notice. <PotentialUser-63>I think this could coincide with the moment I had to recover from the vulnerable Guix daemon issue. <sham1>Yeah, no use going after spilt milk <sham1>Oh well, hopefully you didn't lose too much stuff. There's nowhere to go but up <PotentialUser-63>TBH, I did lose much stuff because I was very productive this week. But this is only a week, and it’s only work I can do again. <jresich>hi guix, I have very slowly downloaded a large (~800MiB) substitute over a 50kbps connection. It took downloading first to another webserver that supports byte ranges, then downloading from there using curl (cont) <jresich>(cont) now that I finally have it, trying to 'lzip -d < ...nar.lz | guix archive --import' it yields "guix archive: error: input doesn't look like something created by `nix-store --export'" <sham1>Just out of curiosity, have you tried to pipe the file directly to guix archive --import without decompressing <sham1>I don't know if that'd work, but just to rule that out