IRC channel logs
2025-04-25.log
back to list of logs
<ekaitz>Kabouik: in the meantime you can exclude the package from the upgrade <ekaitz>Kabouik: --do-not-upgrade is the flag you can use in guix package <Kabouik>Actually I'm mistaken, guix package -u went well, it's my reconfigure that fails due to telegram-desktop (it's in my list of packages). I went afk while it was working and mixed both upgrades, sorry. <ekaitz>oh that makes sense too, your system upgrade has the problem <podiki>(godot: yup, 4.5.2 works too, i'm guessing a bug in 4.5.0 that was fixed in the point releases; 4.5.1 mentions a CPPDEFINES issue, so that's my guess) <Kabouik>I just commented the package out in my config to reconfigure ekaitz. But is this a local issue or really a bug with a telegram-desktop upgrade? This might be the first time I see a faulty patch being merged for a package definition. <ekaitz>Kabouik: first time? you haven't been here for long then <Kabouik>Oh I attribute them to my local mess every time :p <ekaitz>it happens sometimes. It might also be that some dependency got crazy, take a look to that pipewire config. <Kabouik>Now I realize I may have too many packages in my config.scm. I don't use guix home (yet; let me get comfortable with guix itself first, still not there after years!), and my system is single user, so I just thought it would be easier to have all my packages there and easily transfer my config.scm to my other Guix machines. <Kabouik>My relatively important packages, I should have said, not all my pakages. <ekaitz>if you have many packages in your config.scm that makes sense that it failed during the reconfigure <ekaitz>if you had that installed in your user profile you'd have it failing in the guix package -u <Kabouik>telegram-desktop was the only faulty one, reconfigure went well when I commented it out <ekaitz>Kabouik: aaf4bf1491dca1e8cd3bfff85226e244c2af968a this is the most recent commit touching it <ekaitz>you might be interested on taking a look to it <sham1>You can always put your guix home configuration into your config.scm with the guix-home-service-type :P <Kabouik>I'm not ready for guix home yet I think, though I'm sure it's great. Not being fluent in Scheme makes it less beneficial, I guess. <sham1>That wasn't intentional. But yeah, you could easily have a very monolithic config. Probably not that good an idea, however <Kabouik>I guess the issue is more in a dependency of telegram-desktop than that package itself indeed, because that commit is from March 17th and I'm pretty sure I have upgraded my packages a few times since that date. <Kabouik>How come a time-machine with a channels.scm (generated from describe, so with commit hashes in it) and a manifest.scm that used to work in the last two weeks no longer works? I am getting this: https://0x0.st/8Vx8.txt Pretty sure r-dharma was not added recently. <Kabouik>I don't understand how the reproducible environment ceased to be reproducible. Any ideas? <apteryx>is it possible to override/update the value of a configuration-field object? (produced by define-configuration) ? <apteryx>probably no, guix records are designed to be functional, e.g. immutable types. <apteryx>jpoiret: I've sent my own proposal for fixing the elogind problem as a v2 to bug#77806 <apteryx>Kabouik: do you pin your channels to exact commits? otherwise if you simply track a branch, it may change. <vhns>is there a way to have grafts be offloaded as well? <meati>hi guix, i'm running into a strange roadblock while updating 'smalltalk' where a package is failing to build with a final error 'cannot find glib/gwin32.h' despite 1] glib having that header, and 2] this header not being named anywhere in the source code (even post-configure). The build log is too long for debpaste but here is what I have so far on the def: http://paste.debian.net/1371422 <meati>Note, this only started happening once I added gtk2 (so that the GTK library would be built, so that the graphical browser could be used) <meati>Other minor issues are that it can't seem to find Tk and it searches for an sdl_sound that we don't have <meati>Once I can get it built with all the features I'll see about splitting off the libraries/browser/etc. into different outputs to bring the closure size back down <lilyp>meati: is that sdl1 sound or sdl2 sound? <lilyp>sounds like a very old package anyway <lilyp>fwiw, gtk2 propagates glib, which might confuse pkg-config <meati>lilyp: sdl1 sound. I will try removing the explicit glib perhaps <meati>...same issue, still 'cannot find glib/gwin32.h' <wizard>i feel like i remember there being a way to run run a guix home reconfigure without installing / updating any packages <wizard>but i checked the manual and couldn't find the flag <wizard>does anyone here know what that might be? <meati>...okay, I've figured out that that wasn't the actual error, but actually it was an awk script used in building the smalltalk GTK2 library which tried to print to stdout, which caused it to crash. I removed the print statements and now it builds but the GTK2 library has issues. I suspect the print statements were generating files, but if so, why did it try to print to stdout and then fail? Is anyone here more familiar with gnu build system shenanigans <meati>wizard: roll back your guix to match the one used to build your last home, maybe? <podiki>oh, all for riscv64? something new got enabled? <meati>wizard: as in 'guix pull --switch-generation' or '--roll-back' <podiki>(i guess riscv64 is now being built and wasn't before? neat!) <wizard>hm, i don't think that was it exactly <wizard>i could be misremembering entirely too idk <apteryx>from (info "(shepherd) Timers"), "When LOG-FILE is true, log the output of ACTION to that file rather than in the global shepherd log."" <apteryx>what is the global shehperd log? /var/log/messages? <apteryx>reading (info "(shepherd) Invoking shepherd"), I'm not sure what is the default behavior (not specifying --logfile nor --syslog, but I assume it's logging to /dev/log aka syslog.) <ruther>apteryx: yes, shepherd log is /var/log/messages or ~/. <ruther>~/.local/state/shepherd/shepherd.log for user instances <apteryx>is there a 'herd schedule mcron' equivalent for shepherd timers? -> displayed in 'herd status' of timer <xelxebar>Man, the oauth2l package has been broken for a while. <xelxebar>Looks like some tests expecting $HOME/.oauth2l to exist. <Kabouik>guix pull is currently broken over http (502) <untrusem>> guix pull is currently broken over http (502) <untrusem>I am using codeberg mirror for it currently <Kabouik>Thanks, I didn't know the mirror was ready to use <cow_2001>is the endless mercurial build bug fixed? <untrusem>so python is upgraded in guix now, right? <untrusem>both 3.10 and 3.11 have same name i.e `python` <orahcio>Hello, I think I bloke the guix gc, even the command `sudo guix gc --verify=repais,contents` run but after this the `guix gc -d` gives an error, exit code 1: `finding garbage collector roots... <orahcio>guix gc: erro: program `/gnu/store/ngs4yzfz5ib7n3ijfgvf6ymqch5j1cqx-guix-1.4.0-36.0772d36/bin/guix' failed with exit code 1` <QUL>Hi, I'm new to GNU Guix and just found out it and GNU Guix System uses the Contributor Covenant. I am bit surprised since most GNU Projects use the GNU Kind Communications Guidelines. Does anybody know the reasons why Contributor Covenant was chosen instead of it? <cdegroot>QUL: I guess Guix is older than the GNU KCG and nobody ever saw a need to change. <QUL>cdegroot: Oh yeah right I completly forgot that the GNU KCG are new. Makes sense. Thank you! It has been bugging me for a day. <attila_lendvai>orahcio, try providing --on-error=backtrace and see if you can get some more insight <orahcio>attila_lendvai: I will try this, thanks <attila_lendvai>after a recent reconfigure my laptop lost its sound output (only some quiet cracks) and refuses to remain suspended (wakes right up by itself). am i alone? <orahcio>attila_lendvai:Is the flag --on-error póssible for guix gc? <attila_lendvai>orahcio, i'm not sure. it's present for guix system, but there a bit of consistency in the CLI... <orahcio>attila_lendvai: I try --on-error flag, but it has not this flag <attila_lendvai>orahcio, too bad. then try to look into /var/log/messages, maybe there's a hint there <orahcio>First time `guix gc --verify=repair,contents` is not a solution, quicly I will have no free space in my disk without guix gc <PotentialUser-47>Hi #guix! I'm encountering an error I've never had before. The command `guix system reconfigure` hangs indefinitely, and `guix pull` leads to the error <PotentialUser-47>guix pull: error: Git error: SSL error: syscall failure: Resource temporarily unavailable <ieure>PotentialUser-47, The pull error is Savannah having problems, it's been up and down for a week or more. <ieure>Not sure about the system reconfigure. <orahcio>attila_lendvai: I saw this erro after (with sudo and without it) guix gc, on the guix-daemon log: `2025-04-25 11:07:04 guix gc: error: creating directory `/var/guix/profiles/per-user/guix-daemon': Permission denied` <apteryx>jpoiret: hello! i just sent a v3 in the elogind-configuration series (#77806). If you have an affected laptop, could you please try it? I only have a desktop, and it already suspends on power button. <ruther>clone: yes there is, plain-file is a different derivation that is built prior to the package, you cannot know output of the package in plain-file's derivation... You need to ungexp output directly how you saw it in the example - #$output, it's not a normal variable. <clone>Thanks. So for a case like this where I need to reference a file in the packages output in the plain file, would the best way be to put something like OUTPUT in the plain file and then use substitute* to substitute it to be the actual output path? <ruther>clone: no, just don't use plain-file <ruther>clone: it's an unnecessary step to do... <ruther>clone: why make a different derivation when you are already making one? <clone>what should i use to create a file with the text that i want within the derivation? <clone>oh i see, thanks for the pointer <orahcio>attila_lendvai: After this log ao create the guix-daemon directory and I give to that directory correct permissions, now a have again the guix gc. I learned the lesson, always read the logs, thanks <azval>is there any plan to add MacOS support for Guix ? <azval>just wondering if I should still wait a little or just go for MSG (MacOS subsystem for Guix) <azval>no plan at all ? even after it came multiple time in the 2025 feedback ? <apteryx>azval: no plan at all, but there are channels if someone wants to jump through the kind of hoops that nixos has to jump through to support it <apteryx>(to be clear: someone could implement it and make it available via a channel, one of the mechanism through which guix can be extended) <azval>a channel which target Mac hardware I understand, but to install guix itself with the daemon running, is there a way to do that natively ? <ray1729>I'm hoping someone can point me in the right direction with this. I ran `guix pack -f tarball -m manifest.scm` then added the resulting tarball to a minimal Docker base image. All the files I expect are showing up under /gnu/store, but when I try to run any binaries I get an error:/lib64/libc.so.6: version `GLIBC_2.38' not found. What am I missing? <ray1729>(I know I could create a Docker image directly with `guix pack` - that works locally but fails in AWS Lambda for a different reason.) <luca>Hi, is it possible to specify a custom channel when running `guix system` on a forreign distro? <ruther>luca: of course, what system you're on doesn't matter, just pull or time-machine with the channels you want, and run guix system with that guix instance. <ray1729>Answering my own question: one of the underlying Docker layers had set LD_LIBRARY_PATH. Delete this from the environment and the Guix binaries run fine. <ieure>azval, Guix doesn't run on macOS because it's impossible to bootstrap with Free software, because Apple's compiler requires agreeing to a non-Free license. <ieure>azval, NixOS works around this by having some dev agree to the terms, compile stuff, and commit the binaries to their repo. Guix has a stronger commitment to reproduceable, from-source builds with Free software, so this isn't a tenable path. <ieure>azval, Also, Guix depends on glibs and doesn't want to support other libcs; and there is no glibc port for Darwin. <luca>ruther: Thanks, but `guix system image` at least still tries to fetch from git.savannah.gnu.org which is a bit unstable at the moment, even though it's not in my . <luca>* ~/.config/guix/channels.scm <fanquake>ieure: couldn't you cross-compile whatever is needed using non-apple llvm/clang on linux, and commit those binaries? <fanquake>why does it need to be apple clang on a macOS machine? <ieure>fanquake, Guix requires fully from-source packages, so you can't commit binaries to the Guix repo. <ruther>luca: I don't understand what you mean that 'guix system image' tries to fetch from savannah. It would do that only if you gave it channels to fetch in the guix-configuration, and if you did, just change the channels. <ieure>fanquake, As apteryx mentions, if you want to do this outside of Guix, you're welcome to. But binaries in the repo are untenable for the Guix repo. <fanquake>Right, so I guess the nix use case is not related to any license <fanquake>Actually I guess you may still need something license related for the SDK <ieure>There have been a few discussions of this on guix-devel over the years, recommend searching there to see what the issues have been. <luca>ruther: Thanks, seems like a combination of bad lisp and misunderstandings on my part led to fetching from savannah. I switched out `(cons* (...) (list))` with just a `(list ...)` and it now only fetches from codeberg <luca>(i was lazy and replaced %default-channels with (list)) <jA_cOp>Is it possible to specify a crate version when using `guix import crate`? Or does it always grab the latest version? <kyoji>hey #guix! what is the best way to test patch(es) posted to issues.guix.gnu.org? Is it necessary to pull down and compile all of guix from source (applying patches) if the patches in question are only targeting specific packages? <ieure>kyoji, Yes, you have to compile all of Guix (not all the packages in Guix). <ieure>kyoji, Follow `(guix)Building from Git' -- but in between `configure' and `make', run `mumi current THE-BUG-NUMBER' and `mumi am'. <kyoji>ok great thank you, this is what I was missing <kyoji>after building, do you have any recommendations on the best way to test without modifying the running system? <ieure>Depends on the patch. If it's updating a package, you can `./pre-inst-env guix shell THE-PACKAGE-NAME' and run it there. You can also sometimes just run it on the system using the store path `guix build' prints. I do that for LibreWolf. <ieure>If it changes deeper Guix stuff, you'll have to `./pre-inst-env guix system image' to get some sort of image you can test. <kyoji>what if its a system package? Specifically I'd like to test some patches posted for GNOME <kyoji>Thanks this puts in the right direction, appreciate it <ieure>kyoji, I understand the desire not to mess with the system state, but it's honestly very safe with Guix. ex. you can `./pre-inst-env guix system reconfigure' and test things out, then `sudo guix system roll-back' to go back to your previous configuration. <ieure>kyoji, And if things break so badly that your system gets horked, you can reboot into the previous system generation. <kyoji>I'm not opposed to any approach, just getting a feeling for what those with more experience do <ieure>Actually, now that I'm saying this, I think it's difficult to reconfigure your system with the pre-inst-env because of the need to use sudo. <ruther>ieure: it's not really 'difficult', you just either use root shell directly, without sudo, or use sudo -E, but you can possibly end up with root owned files in the tree that way <vhns>oh well, renaming dots/.authinfo to dots/authinfo fixed it <luca>Pass another argument to local-file without a dot in it <luca>Like (local-file "dots/.authinfo" "authinfo")