IRC channel logs
2025-08-06.log
back to list of logs
<nomike>Sorry, meant to say "Unbound variable: remove". <nomike>I believe i need to add "(srfi srfi-1)" somewhere, but I'm not sure where and how to do this in a syntactically correct way... <identity>nomike: probably in the #:modules in the argument list, see how other packages do it <podiki>probably where you are using it (e.g. in a variable rather than function position) <vagrantc>Gooberpatrol66: you may have to reopen the issue first <vagrantc>Gooberpatrol66: you would presumable have to send an email to the control address... <Gooberpatrol66>for some reason mail.gnu.org and lists.gnu.org don't load for me. started happening like a week ago. <dynamoe>hi! just installed guix distro on my pc and it works so far but the graphics are wrong. everythings "green". i guess theres something wrong with the driver but I have no idea how to get this right <dynamoe>Someone here to help me diagnose the issue? Please :) <freakingpenguin>Hey all, does anyone here use darktable with opencl? The option is grayed out in darktable preference and I'm wondering if I need to install another package. Using an amd gpu. <freakingpenguin>Ah, I see that if I have a profile containing e.g. darktable + pocl, the OCL_ICD_VENDORS env var is undefined so opencl-icd-loader doesn't find pocl. opencl-icd-loader has to be in the profile to register the search path, not just be an input to darktable. <apteryx>what's the mount helper program name for fat32 ? <apteryx>TRAMP in Emacs 30.1 appears broken for me ATM with 'couldn't find command `ls'; anyone else? <podiki>that's a familiar error from the past, probably the patch we do for tramp needs to be updated? i think last time it was because "ye olde substitute will fail silently when it doesn't match" <podiki>we should make that an error and spend time fixing anything that breaks because of it <apteryx>podiki ah, so that 3 yo patch got merged, but probably got broken again? <apteryx>maybe using a plain .patch until substitute* can be made to error out on a no-op would be safer here, since it seems the underlying code changes often <apteryx>sham1: nah, we want substitute* itself to error when it does nothing <apteryx>otherwise we'll miss tons of no-op when the undelying code changes and the existing calls become ineffective. <untrusem>ok libreoffice substitutes are not there yet <mawumag>hi everyone, I am trying to use the guix-jupyter kernel, but whenever I try to create an environment, the kernel crashes with the error: <mawumag>if anyone has any ideas what might be going on, that would be great :) I am running guix as the OS <csantosb>Would be nice to specify in the commit message the reason (or a ref to) why a package is removed <andreas-e>csantosb: I have been removing lots of packages of which we have a newer version, when the old version was not used anymore. So in a sense this was "obvious" to me. <andreas-e>Usually these are packages with variable names like something-1.17. <andreas-e>For others, I have added a "Fixes:" line to the deprecation issue on codeberg, but only for the last of a series of commits. <csantosb>Not today, but in six months we need to know precisely the reason why certain packages were removed in the past <bvd>Is there a way to specify a URL for guix package like there is for guix pull? <Guest3763>Has anyone some posts or else to share about this topic from more recent times? <efraim>but I haven't seen a full router config that I remember <Guest3763>Oh this is pretty cool, thanks for sharing. Really helps to have some specific examples to wrap my head around guix' unusal config <ekaitz>does anyone have a good tutorial about running a database service (postgre) in guix in a way that I can clean easily later? maybe guix vm? <ekaitz>oh we have a cookbook page for this! <ekaitz>what I don't understand very well is where's the data to be stored...? <Kabouik>`gpgconf --list-options gpg-agent | grep loopback` returns "no-allow-loopback-pinentry" on my machine, yet I have "allow-loopback-pinentry" in my ~/.gnupg/gpg-agent.conf and apparently it's not even necessary since gnupg 2.1.12 (it became the default). Is it something to be set in config.scm somehow? <ekaitz>Rutherther: btw thanks for that proxy you set up for IPv4 for the unspeakable channel. Life saving! <ekaitz>damn where is the `guix system container` storing its things? i don't understand... I'm not sharing any folder! <ekaitz>stupid questions that i have after 6 years using guix and contributing to it... i'm a genius <ekaitz>andreas-e: isn't the store inmmutable? <ekaitz>i found the /etc /boot and so on, but where's the data itself the container uses, like logs and such <andreas-e>I am trying to create a Guix container from a dockerfile as part of a gitlab-ci pipeline. At the end I do a "guix pull", which probably takes one hour before telling me that I made a mistake... Rinse and repeat... <andreas-e>ekaitz: Okay, I misunderstood the question. The initial container is in the store. But then you load it into docker, no? Which probably runs on a copy then. <ekaitz>i'm running the container with the script that it comes with <andreas-e>And probably I am also mixing up images and containers, anyway. <efraim>llvm-18 and llvm-for-mesa are failing to build on ppc64le <ieure>ekaitz, High-level and someone will probably tell me I'm wrong, but Docker overlays a temp FS on top of your image when it runs, writes go there, but are discarded when you stop the container. <ekaitz>ieure: that's interesting! and when I --expose things i guess that becomes part of the directory I exposed <ekaitz>let say, i have a postgresql, which I believe stores things in /var/lib/postgre or something, so if I expose that directory to somewhere I would be able to recover it? <ieure>ekaitz, --expose creates a bind mount inside the container which directs writes back to some directory on the host filesystem. <ekaitz>and if I don't --expose data is lost when I shutdown the container i understand, right? <ieure>ekaitz, You can use a bind mount or create a volume and mount that. Volumes are Docker-managed filesystems, essentially, they end up in /var somewhere. <ieure>But yeah, unless you have some FS mounted inside the container, all its writes will be lost when it's stopped. <ieure>ekaitz, Not sure what tool you're using, I think --expose is for networking with the docker CLI. -v or --volume is what you use to manage mounts inside the container. <ieure>I believe `guix shell -C' uses --expose for FS stuff. <ekaitz>i'm using whatever guix system container does, i'm just playing around with the cookbook <ieure>Gotcha, yeah, --expose does something completely different there than the docker command. <ieure>Yeah. `guix system container --expose' -> manage mounts inside the container; `docker run --expose' -> manage which host TCP ports forward into the container. <ekaitz>oh I see so it does what I expected, right? <ieure>--expose works the same in `guix shell -C' as `guix system container' <ieure>ekaitz, Yes, it bind mounts stuff from the host into the container. <ieure>I just wasn't sure if you were using the Guix command or some container runtime client tooling. <andreas-e>I added the pull requests as an additional origin to my git checkout, as suggested by civodul on guix-devel. However, this only ever grows; I would have assumed that "git --prune" would remove closed pull requests. Does anyone of you know how to do this? <efraim>my config prunes branches once they're deleted by their remote, I'll try to figure out which option it is <andreas-e>This is "git fetch --prune"; but I am afraid that codeberg does not delete merged pull request branches. <efraim>oh, true. I see many many PRs in tig <andreas-e>Maybe something to change in our codeberg settings? But then we would probably lose history. <andreas-e>Hm, I am doing the first "guix pull" in my docker container image; this takes ages, so far 40 minutes just for cloning the repository. Is it theoretically possible to start a git checkout only at a given commit? For instance, the last release; even at the price of not being able to go back too far with "guix time-machine"? With this container, I do not want to go anywhere anyway, to update it, I would recreate it from scratch and do a new <ieure>andreas-e, You shouldn't be pulling inside the image IMO. The image should have whatever version of Guix was used to create it inside; you want to pull from your host, then make a new image from that. <ieure>Sorry, "shouldn't be pulling inside the container" <andreas-e>ieure: Well, I would like to use the gitlab CI itself to create a container. This would happen maybe once a year or so. And then I could wait a few hours (right now, one hour looking at "Updating channel 'guix'"), and I am afraid there will be a mistake after that and I will have to start from scratch. <andreas-e>But the question also occurs with regular users. I tried a "git clone" from Savannah; I had a download rate of about 500kB/s, for a total of about 8GB. Otherwise said, about half an hour. And sometimes people have much lower bandwidth. <andreas-e>And it is the first thing you do after installation. <andreas-e>So renouncing at time travel to the past, before the installation, would be a reasonable trade-off. <andreas-e>But is this possible with git? A clone just of the last commit, with the possibility of going forward nevertheless? <ieure>andreas-e, Git has a mechanism for this, it's called "shallow clone." I don't believe Guix has any way to use it, though. <andreas-e>ieure: Okay! I thought that would just give you a snapshot, without possibility of "guix pull" afterwards. <efraim>looks like it might be guile-git that needs to support it <andreas-e>efraim: Another option for me right now (but somehow less nice) would be to create the binary installation tarball. But how? We have this target in Makefile.am: guix-binary.%.tar.xz <ieure>Well it's all moot since presumably andreas-e is bootstrapping from Guix 1.4.0, which cannot possibly have the needed support. <andreas-e>But "make guix-binary.x86_64-linux.tar.gz" does not find it. <ieure>andreas-e, Git doesn't store snapshots. `git clone --depth=N ...' will give you a clone of the N most recent commits. For N=1, Guix is ~213mb. You can pull the repo, but can't look further back in history than N commits. <andreas-e>efraim: Your libgit2 link looks promising to add to guile-git and guix! <ieure>andreas-e, You could maybe cheat by prepopulating ~/.cache/guix/checkouts with that, then pulling? <andreas-e>Indeed I am having two conversations at the same time :) How to solve my current personal problem. And how to make the first "guix pull" a more pleasant experience. <andreas-e>ieure: In this case I cannot prepopulate, because it all comes from a textual docker file, where I install Guix "by hand" into a preexisting Debian image. So to populate a checkout, I would have to do a "git pull" anyway. Which is more or less the first stage of "git pull", maybe faster. <efraim>what about that magic snippet to pull to a commit that already has substitutes built for guix-pull? I've used that in the past <efraim>andreas-e: you can use the timeout command to kill the first guix pull so you know what directory to use for creating the shallow clone <andreas-e>So far, I am really just at the stage of pulling the repository. It is not about substituting or building packages I want to install later. I am not even yet at "computing Guix derivation". <andreas-e>Ah, I had misunderstood; you mean populate "by hand" by a shallow clone. Interesting idea! <ieure>andreas-e, Most of the problems with `guix pull' being slow are libgit2 performance issues, like this one, which has been open for six years, which someone actually investigated and provided a patch for over a year ago, which has not been merged: https://github.com/libgit2/libgit2/issues/5271 <a6Y37l>I ran guix-install.sh yesterday to successful completion. Then I did a search for documentation and found quite obstruse documentation on this package still haven't figured what next to do to make guix pull able to work without throwing errors. <ieure>a6Y37l, You may want to post to the help-guix mailing list. <andreas-e>ieure: Ah right, we even considered using the (invoke "git"). <andreas-e>efraim: Do you remember how to create the binary release tarballs? <andreas-e>I thought this was what I had tried before... <andreas-e>On my gitlab ci, it failed after about 45 minutes without any further message. Probably a timeout. <efraim>yikes, got llvm-19 FTBFS on ppc64le also <efraim>trying now to build llvm-18 with gcc-13 <vagrantc>wow. i got into some weird state where "guix system reconfigure" ... takes effect, but the symlinks in /var/guix never get updated anymore <vagrantc>e.g. when i reboot, it reboots into the new generation ... but "guix system list-generations" never changes anymore <andreas-e>efraim: I would be surprised if you needed gcc-14 only on powerpc. What is the error message? <efraim>andreas-e: different tests from tests/tools/dsymutil/X86/DWARFLinkerParallel failing <efraim>i'm going to try disabling parallel tests and see if that makes any difference. it seemed to have fewer failed tests when I built it with 12 or 8 cores vs 48 <jerops>Hello! I'm currently working on translating Guix into Russian and I have a question. So, I translate the strings directly on the translate.codeberg.org website and there is a lot of Scheme source code around the texts that you don't have to translate. If I just copy such a string as is, it warns me that it isn't translated but there's usually no <jerops>other way except translating comments. Should I just leave them untranslated? <tachymelia>heyo have any of y'all used agit for pring to guix? every time I try to use force-push w agit-flow it just complains about not being able to read from remote repo. it's able to read fine when I don't provide force-push (but then it complains abt needing it) <vagrantc>i vaguely recall needing a special option to enable force-push <andreas-e>jerops: Not sure if anyone working on translations is around here; if you do not get a reply, I would suggest sending an email to guix-devel@gnu.org <tachymelia>vagrantc: -o force-push=true right? when I provide that it does the, can't read from remote repo thing <tachymelia>??? okay so. I. provided an unnecessary title and description (unnecessary bc it's a pr revision) and did both methods of providing a topic, and it worked. idfk <vagrantc>i am a bit confused about how to proceed on getting the kernel updates merged ... the kernel-updates branch has gone stale compared to master, so simply rebasing the commits and pushing would mean no substitutes ... <vagrantc>on the other hand, this branch has been idle for over a week and newer kernel versions are already available <vagrantc>tempted to rebase and push an updated kernel-updates branch, if i have the permissions to do that... <vagrantc>then CI should start building out the updates... <andreas-e>vagrantc: Normally it should be enough to rebase on master and force-push the branch. Then CI should pick it up, and tomorrow there should be substitutes. Then you could rebase on master and push to master. <andreas-e>CI shows 504 errors all the time; but I think it nevertheless works in the background. <andreas-e>Anyway, you will see whether it works from the availability of substitutes. <andreas-e>All the kernel packages from last week are still marked as only "scheduled". <vagrantc>andreas-e: yeah, the 504 errors make these ... extra fun <andreas-e>No, sorry, this is aarch64. So they should be okay on x86_64 and i686. <vagrantc>andreas-e: yeah, for x86_64 there are substitutes availble for the kernel-updates branch, but they are obviously out of date <vagrantc>andreas-e: rebased kernel-updates branch and pushed <vagrantc>ACTION tries to wrap head around the process to update to current released versions... <vagrantc>as there are three more updates since that <andreas-e>vagrantc: There are new kernels every week, right? That is much faster than what we can handle. We just have to skip versions. <vagrantc>andreas-e: that's fine, but it feels silly to have the merge request, have all the substitutes, and then let it sit there unused <vagrantc>seems like that is doing all the work for little to no benefit <andreas-e>Well, that happens! You can be faster next time. <vagrantc>yeah, will see if i can get the ones from 5 days ago ready in time to merge ... <vagrantc>i have suddenly taken more interest in the kernel updates, as the mnt/reform kernels have patches that may need rebasing, and i've been using guix on my mnt/reform <vagrantc>(although that is the machine with the bizarre issues with reconfigure at the moment) <andreas-e>You still have the original imx board, right? This is so incredibly slow... I think its four cores takes twice as long as the two on my almost 9 year old x86_64 laptop. <vagrantc>andreas-e: i have the board, but i have upgraded to a newer, much faster rk3588 board with 8 cores and 32GB of ram ... that was basically when i switched to testing guix on it :) <andreas-e>Ah, I see! As a data point, how long does a "guix pull" take? <vagrantc>well, testing Guix System ... i had experimented with guix as a foreign package manager with the slow cores <vagrantc>guix pull ... is still unpleasantly slow ... have not timed it recently ... and substitute availability for aarch64 is a bit spotty <andreas-e>Just for testing whether a package builds on aarch64, the slow board is usable as well. <vagrantc>but kernel compile in 30-40 minutes ... maybe guix pull in 10 minutes? <andreas-e>On the bordeaux build farm, I think substitute availability must be about 100% of all the buildable packages. <vagrantc>not in my experience, but i probably pull too often :) <vagrantc>andreas-e: 10 might be optimistic ... but probably no more than 15 <vagrantc>beats the 45 minutes or so when i was running on the imx module :) <andreas-e>I think my old laptop needs about 30 minutes, and the aarch64 about an hour. <vagrantc>andreas-e: would really like to try and make an image for you to test with the imx8 mnt/reform ... but have not gotten around to it <andreas-e>No problem! I am just too noob to do it myself :) <vagrantc>andreas-e: mainly, just getting the lsmod output from running debian and then adding all those modules in your system config.scm ... <Deltafire>i wish we could tell guix to skip packages which don't have substitutes built <Deltafire>i don't want to wait 12 hours for icecat to compile <ekaitz>Deltafire: you can now, that you know there are substitutes <podiki>guix is building something but i don't know what or why.... how can i find out <podiki>i assume something i have that runs a guix shell is needing to rebuild something after a pull <Deltafire>doesn't look like --do-not-upgrade can be used with system reconfigure :( <Deltafire>podiki: nothing useful in the process monitor? <podiki>well i see all the build processes but that doesn't answer my question really, don't know where they come from <podiki>trying to look at a process tree but not getting far <podiki>i need to know what originated the guix commands, not just see that they all come from the daemon <Deltafire>do you have unattended-upgrades setup? i sometimes find it's busy recompiling the kernel or something <podiki>the only thing that could be happening would be some process that wants to guix shell something (i use that) but all the ones i found are fine (don't need a rebuild) <andreas-e>I am probably naive, but you can see the what in /tmp/guix-build..., no? <podiki>yes, i do know gfortran is being built <podiki>why though (and was that some recent gcc changes i saw causing a gfortran rebuild?) <podiki>may also just be in a loop building gfortran too, seems to finish (ld processes) and then back to cc1 <podiki>nevermind, it is on to llvm now :-| <ekaitz>Deltafire: i'm not judging but why do you have icecat in your system? i have that kind of packages in my profile so I can upgrade and manually avoid them when things go south <luca>Hi, anyone got an example on how I can use greetd's initial-session-command? I tried passing a file-like and it wasn't happy about it <podiki>(i decided to log out/in and now no random guix building....how odd though) <sneek>Welcome back valorzard, you have 1 message! <sneek>valorzard, ArneBab says: the LGPL is not a problem for proprietary platforms per-se, but there are challenges due to app-store policies. These are shared by Qt, too, though, and there are practical solutions: www.objc.io/issues/17-security/inside-code-signing/ <valorzard>I've been trying to figure out how to compile a simple guile program. <valorzard>how do i compile that using guix into a standalone program that prints hello world, and how do I cross compile that to windows?