IRC channel logs
2026-05-04.log
back to list of logs
<GalaxyNova>I am not sure if this is the right place to ask, but has anyone else been having a strange issue when using Geiser in Emacs with Guix? For me, after I compile a buffer with C-c C-b and switch to the repl, Emacs freezes for about 20-30 seconds <lilyp>Compiling an entire buffer with a codebase as large as Guix is likely to cause issues; it's probably the Guile process inside of the REPL that hangs. <lilyp>running multiple emacsen i guess <lilyp>Geiser could also detect the blocked communication asynchronously and allow you to do other stuff, I guess <noe>GalaxyNova, did you run make? <Kabouik_>I can't wait for the php PR to be merged, this is blocking my upgrades. :< <efraim_>I was hoping to finally check out the pascal bootstrap and leave notes but I guess I'll have to wait until later for that part <efraim>also i'm currently building python-minimal on powerpc so I think I have another hour or so until that finishes <orahcio>Kabouik_: I joined here to ask about Codeberg, thanks <Digit>ACTION checks... codeberg's up here <yarl>The only way to check which channel a package comes from is to look at package-location? <yarl>And that's probably irrelevant in case of in home-or-system-configuration or manifest declaration <cluelessguixer>For a shepherd timer, how do I log recent messages? Seems it only logs the most recent run, providing no history. <sham1>Hm, apparently if I try to add a user to `guix-home-service-type` with `simple-service` extension, the home environment can no longer be found with `guix home reconfigure` <sham1>I guess this means that we should fold the services up before trying to find the home-environment from the operating-system services <identity>cluelessguixer: ~/.local/state/shepherd/ might have logs <civodul>cluelessguixer: ‘make-timer-constructor’ accepts a #:log-file argument, to store the log in a file <civodul>otherwise it ends up in the default log file, like /var/log/messages <identity>…not sure where i got the idea you were asking about home shepherd, but yes, for system shepherd the logs go to /var/log/messages by default <cluelessguixer>identity: civodul: I guess I'm actually asking about both? I have a user script run to clean up .bash_history, and since I had some issues having this shepherd timer in my system.scm file (commands like rm and sed suddenly not recognized), I've moved it to my home-configuration.scm file instead, which seems to work fine. I actually did find a history in shepherd.log, but it would be nice to see it when using herd status. <anemofilia>I have both aspell and aspell-dict-en installed via guix-home, but aspell can't find the dictionary <anemofilia>+radio at phenex in ~ > aspell -d en check file.tex <anemofilia>Error: The file "/home/radio/.guix-profile/lib/aspell/en" can not be opened for reading. <identity>anemofilia: you probably need to set some environment variable <anemofilia>Couldn't find any *SPELL* environment variables, and my DICPATH for somereason has only hunspell things, I don't even use hunspell <identity>for some reason it works fine for me without any special setup, though <yarl>Is the only way to know from which channel a package comes from is to look at package-location? <ieure>yarl, I believe that's the only way. What's your usecase? <Rutherther>yarl: depends where you're seeing the package, ie. in a user profile the most reliable would be looking in its manifest <Rutherther>if in a scheme code, then where the reference leads... it all depends on context <yarl>Rutherther, ieure in home-environment, for example <yarl>home-environment-packages <Rutherther>but where in home-environment... are you talking about what has been produced by guix home build or what you see in code? <ieure>yarl, Yes, but, why do you need this? <yarl>I'm looking for a way to know what's farest revision I can reconfigure without building (i.e. with available substitutes) <ieure>What do you use the source channel for when determining that? <yarl>by looking at data.guix.gnu.org, probably <yarl>I don't know yet, I'm experimenting things here... <ieure>Is there a similar service for any other channel? <Rutherther>note that even if you will find the channel, you will still not know what package to choose if there are multiple with the same name <Rutherther>you can never know until you actually evaluate the code with the new revision, you can only guess <Rutherther>moreso if you used specifications->packages and package appeared with same name elsewhere or scheme symbols and symbol of the same name appeared in different module, you could also end up with different references afterwards. <Rutherther>I think you will have easier time if you just use time machine to a couple of commits and actually check the substitutes available for those commits rather than guessing at package level <Rutherther>and that's not even taking into account that looking only at home-environment-packages looks only at part of packages necessary for building the home environment <ieure>Agreed. I'm not sure how you detect if substitutes are missing for that, is there an inverse of --no-substitutes? --no-build or something? <Rutherther>because some will also appear from services you are using <yarl>Rutherther: I know, starting simple <ieure>You'd also want to check the package itself, right? Some are not substitutable, so will always build locally. <Rutherther>I disagree I think you're starting the hardest way possible <yarl>Rutherther: I mean by looking only at environment packages <Rutherther>starting simple would be looking at new available commits and bisecting on guix time-machine --commit=X -- home build --dry-run <Rutherther>one level up would be looking at data / ci for knowing what guix commits have been built by them to know what --commits to throw away <Rutherther>ieure: I think that if you use --max-jobs=0 you will get no local builds. However it might be better to just look at --dry-run - or rather maybe doing some Scheme calls to programatically check result of dry run rather than parsing strings <Rutherther>then of course as you're saying sometimes you have to expect you will build locally, so if you want to do this programatically you either have to evaluate if something is 'local build only' or start with a heuristic according to some known numbers of derivations to build according to your own home environment <yarl>I'll keep experimenting. <yarl>So, just to have a clear answer. When I have a package (evaluated, that is a package record) I have no reliable way of knowing from which channel it comes? <yarl>You told me how you would do but I need to try things myself or I'll never learn. <yarl>(I didn't get everything you told me, that's a clue) <Rutherther>if you have it evaluated in scheme, you can use package-location as you suggested <Rutherther>however that's not necessarily the same evaluation as after you pull <yarl>I mean I don't understand. <Rutherther>yarl: but if you want to actually map the channel out of package-location, you might want to use package-channels out of (guix describe) <Rutherther>that will take the source location and find out the channel based on it (it's a bit more complicated, but that's the gist of it) <yarl>hmmm, I missed this function <yarl>Could you explain "however that's not necessarily the same evaluation as after you pull" <Rutherther>okay, simple realistic example - take "linux-libre" symbol as an example, it maps to a specific kernel version, right now linux-libre-6.18. There is also linux-libre-6.19 already. Presumably at one point linux-libre will be updated to 6.19 or 7.0. So based on your current evaluation of "linux-libre" symbol you cannot say what version of linux libre to look for in the target channels <Rutherther>I used linux-libre as example since I just recall it well on this package. It's not what you will use on home environment, but there will be similar examples that are more relevant <yarl>Hmm, correct me if I misunderstood you example, but I am not sure that's how I plan to do. That's not the pull I am limiting, that's the reconfigure. Say my current home is at revision A, my current guix (last pull) is at C. of course A < C. I search for the revision C that is the closest possible to B (between A and B) with substitutes for all home-environment-packages (a beginning, then I look at services) <Rutherther>if you already pulled, why don't you evaluate with C? <yarl>Because I want to avoid local builds of packages <yarl>Sorry, I'm confusing myself <yarl>But packages my not being already built on ci <Rutherther>anyway, my point addresses the part 'with substitutes for all home-environment-packages', saying that you will not be able to match the packages well for packages with multiple versions available <yarl>Why? I have package-version. <Rutherther>you have package-version of the original revision, the version could've changed in between the revisions <yarl>Anyway, I borrowed enough of your time and I need to work alone a bit on this as it's obviously confuse. <yarl>And I have to get cooking. Thank you for the chat. <meatoid>hi guix, i am trying to prepare a fresh image for a server and i'm testing the config using `guix system vm`. However, when I try to build, I get the error `EFI bootloader required with GPT partitioning`. I already have bootloader set to `grub-efi-bootloader`, what is causing this error? <Rutherther>specifically the issue is that there is no GPT partitioning in the VM, the message goes both ways, it's confusing <Rutherther>it's not telling you you need EFI bootloader, it's telling you you need GPT <meatoid>also, how can i get consistent formatting/indentation in config files? even different installs of emacs seem to indent differently <meatoid>i think the emacs-guix package affects it, but that package seems to be broken on the guix i pulled this morning <kestrelwx>meatoid: You can persistently set indentation and other rules with '.dir-locals.el', like it'd done in the Guix repo. <cluelessguixer>I don't suppose previous runs can be listed under "Recent messages"? Or maybe customize "Recent runs" instead? Also, I'm playing with the idea of having a total of lines removed since inception of the service. I don't suppose there's a more clever approach than just having the script print the total to a file? https://bpa.st/CGTA <ieure>cluelessguixer, Do you see more messages when you use `herd status -n', as the output suggests? <ieure>Seems like a bug? It explicitly says to use -n to view more recent messages. <ieure>I am pretty sure this used to work. Are you sure it doesn't? <cluelessguixer>I can confirm previous "Recent messages" in the shepherd.log file, but only the most recent run is printed. <cluelessguixer>I assumed that was intended since depending on what service is ran, there's enough under "Recent messages" even if it only lists the most recent run output. <PotentialUser38>Hello. I was looking at the build recipe for package Warzone2100. It starts with "mirror://sourceforge/warzone2100/releases/". However, it does not contain the more recent release (4.7.0, from April 7). How/when are the mirrors updated? <ieure>PotentialUser38, I believe it should fall back to directly fetching from Sourceforge if there are no mirrors. <ieure>PotentialUser38, Did you read the first part of the message? <cluelessguixer>ieure: Interestingly, it seems -n option for herd status shows a maximum of 20 lines? Tried with 500 for my docker-jellyfin OCI container, and that's all I got. <ieure>cluelessguixer, Are there more than 20 lines in the log itself? <cluelessguixer>ieure: Since docker-frigate enjoys printing a lot it was easier to confirm with that. Same thing, only 20 lines with -n 50 despite clearly more in /var/log/messages. <PotentialUser38>ieure Yes, I did read it. It says it is not implemented and it then tries to go ahead and do something, which I find confusing. <ieure>PotentialUser38, Yes, but you can understand how, when you're asking for something not supported, it will not work, right? <ieure>PotentialUser38, I agree it should not proceed, but it seems pretty clear why, when it does, that doesn't work. <cluelessguixer>guix pull -l show me on commit: c1aa2c04ba175ad683a74cfc42c71435675bb8c1. <kestrelwx>You would want to make a variant of the package that uses the latest release of Warzone. <PotentialUser38>Yes, I do understand. But the behaviour I would expect from that message would be for it to fail immediately. I have nothing against it trying anyway, but it does raise a few questions (for me, at least). <ieure>PotentialUser38, Yes, I agree, it should not do that. Definitely open an issue about it. <PotentialUser38>ieure: Certainly. I understand the failure. The expectations drop to zero from that point onwards. <ieure>Not sure what you mean by that, but okay. <PotentialUser38> ieure: I'm sorry. I meant to say that as soon as you see "not yet implemented" you know you have reached a dead-end and you need to try another route. <ieure>PotentialUser38, Ah yeah, I see. I was going to suggest that you try a no-version-specified `guix refresh', but it looks like Sourceforge behavior has changed since that code was last touched, and doesn't work either. <ieure>Looks like the SourceForge URL structure has changed. <PotentialUser38>kestrelwx: Thank you for contributing with a possible solution. I think I would be able to make the minimal edits necessary to point to the newer version of the code (i.e., changing the release number and the digest). But I believe that is kind of what the package transformation option does. Please correct me. <meatoid>hi again guix, i'm still trying to build a virtual machine image. Now, the build is stuck with 'partition.drv' failing; the error given in the build log is 'sqlite-error [...] databases locked' <meatoid>Does this have to do with the fact that i'm running guix atop debian? if so, how do i fix this <ieure>meatoid, Usually means you're running a concurrent `guix' operation, like a reconfigure. <meatoid>oh, is it because i'm already in a guix shell? <kestrelwx>PotentialUser38: Yeah, normally that would be enough. <meatoid>ieure, is it possible the database was accidentally left locked? <ieure>meatoid, I have never encountered this, but it is possible. <ieure>I'm not sure if it's different on a foreign distro, but my Guix System has it in /var/guix/db. <meatoid>actually, why would it be able to build the rest of the vm image's prerequisites if the database was stuck locked? maybe this is some kind of concurrency problem? <ieure>meatoid, Are you sure it was an error? My experience is that Guix will notice the lock and retry a bit waiting for it to free up. <meatoid>ieure, it says 'guix system: error:...', in the output <meatoid>would it be helpful to paste the build logs? <ieure>meatoid, Always. Using a pastebin, not directly in the channel. <ieure>meatoid, I see. I'm not sure why the build is failing like that. <meatoid>i will see if rolling back to 1.5.0 helps <meatoid>nope, same issue (at least it isn't an upstream bug) <ieure>meatoid, Was the guix pull from this morning your first since installing Guix on this distro? <ieure>meatoid, It's worth filing an issue, I would expect this to work. I assume you're not doing anything too bananas in the image declaration? <meatoid>no, it's dead simple. i'll file an issue <mwette>Anyone have prusa-slicer building on x86_64? It does not for aarch64, due to cast errors in unittests/*map.hpp. I'll work a fix but wanted to see if I need to make it per-arch. <ieure>mwette, `guix weather' reports x86-64 substitutes on a system I pulled yesterday, so I believe it is building. <mwette>ieure: thanks. It looks arch-specific, since (on linux) char on x86_64 is signed and on aarch64 it's unsigned.