IRC channel logs
2025-12-03.log
back to list of logs
<gabber>so i should wrap a (with-directory-excursion) around my (invoke ...)-ation? <gabber>... assuming python automatically adds (cwd) to its PYTHONPATH <mwette>gabber: slightly off topic ... Is Xyce still doable? I gave up building a while ago and when I checked months ago, I could not get the sources. <Rutherther>no, rather just use the "add-installed-pythonpath" that's meant for this. Or move your phase after add-install-to-pythonpath <mwette>I have used both ngspice and xyce in my AVR simulator. <gabber>mwette: good question. i have no idea! csantosb may be more up2date with these things..? <gabber>mwette: well, we have xyce in both serial and parallel packages. they just got updated <gabber>Rutherther: nice, it works! thanks! <mwette>gabber: in guix; sweet! surprize of the day for me. thanks <gabber>mwette: thank csantosb! they have been packaging stuff like mad! <mwette>sneek: later tell csantosb, thanks for the ngspice & xyce support <flurando>Cuirass still does not work, after adding list as suggested by gabber. Now its config shown in browser even only shows guix channel without mine. I would like to reboot the server to see if there would be any difference <sneek>flurando, you have 1 message! <sneek>flurando, gabber says: would wou mind opening an issue on Codeberg about that documentation bug? <flurando>gabber: I don't mind, but I would like to open one only after I figured out a working version. The add (list ...) does not work still. <flurando>I think build channels functionality is broken in Cuirass. And actually the problem is not a missing (list ...) either. As in cuirass web interface, when manually clicking and pick channel to build, it does not use (list ...). <flurando>Talking of opening an issue, I am considerring to open an issue to Cuirass instead of Guix documentation. <flurando>Wait, it does not even include my channel in the channels.scm and channels.json. HOw come? <flurando>Have removed authentication part, now only naming is different from the guide, would check if it works later <bdju>Couldn't seem to upgrade earlier due to a python mess. I don't think I skipped anything but I was getting conflicts. Then I tried to skip things to get past it but it just keeps coming up with new things I gotta skip. Seems to happen a lot with the python packages. <bdju>Both the listed things have the same version numbers, annoyingly. <bdju>Different hashes, though. <bdju>First it was magic-wormhole, then eyed3, then python-matplotlib, urlscan, etc. <bdju>I guess the actual conflict it mentions is python-cffi. <ibu>Hi there, I'm quite new to guix and even newer to IRC - so bare with me :)Â I started writing package declarations for guix - and actually got it working. However, I still have some issues with my setup and hope somebody can help. I have a VM running the Guix operating system - there everything works fine. But I also have a Debian with Guix as a <ibu>package manager and there things are not optimal. One problem is: when I run `./pre-inst-env guix build xyz` I get many warnings like follows: <ibu>;;; WARNING: loading compiled file /home/user/guix-tok/guix/ui.go failed: <ibu>;;; In procedure load-thunk-from-memory: incompatible bytecode version <ibu>;;; WARNING: loading compiled file /home/user/guix-tok/guix/i18n.go failed: <ibu>;;; In procedure load-thunk-from-memory: incompatible bytecode version <Rutherther>hi please don't send multiple lines here, better use a paste site <Rutherther>just paste your logs to site such as paste.debian.net or what you prefer <Rutherther>as for your problem, I would think this could be file corruption, try removing the files and regenerating them with "make make-go" <ibu>Actually just wanted to do 'newline' but then the text was sent. Ah I see. But i'm done for now with logs :) <ibu>Previously, I did `make clean`, `make -j4` as suggested in some documentation. But will try `make make-go` right now. Usually takes a long time. <Rutherther>you might first need to delete the files, they might not get regenerated due to modification times <ibu>Doesn't `make clean` delete all this files? <civodul>ibu: the âincompatible bytecode versionâ warning suggests that some .go files were compiled by a Guile version different from that youâre now using <civodul>this could happen if youâre say using guile@3.0.9 but previously compiled with a newer version, like âguile-nextâ <sneek>Welcome back csantosb, you have 1 message! <sneek>csantosb, mwette says: thanks for the ngspice & xyce support <ibu4>yes codeberg is under DDoS since yesterday evening <cbaines>I'm going to look at trying to copy the logs.guix.gnu.org/goggles state from bayfront to guix-hetzner-2 today <civodul>cbaines: oh good, i totally overlooked that <civodul>Rutherther: iâm planning to tag shepherd 1.0.9 today <civodul>going to be more difficult if Codeberg is down tho :-) <csantosb>civodul: you can still use ssh, by the way, but not the gui <PotentialUser-96>Hi all. I want to install guix as my main system and I have some questions with no answers in doc. Can I not install grub in any way if I already have one in my coreboot? Can I recompile kernel with my own config and patch kernel sources? I remember that earlier permitions on all files where 444, so can I change them how I want to improve security? <Rutherther>As for grub, note that with every system generation, the linux/initrd parameters you supply do change. So not letting guix take care of it means you are going to struggle with knowing the parameters for boot <PotentialUser-96>I just generate my own initramfs with my own init script to apply many different system parameters at boot level, so any automation is causing some portion of anger as it breaks my bootchain and adds more attack surface) <PotentialUser-96>And I just write to grub config two lines at every update: kernel and initrd and nothing more. <PotentialUser-96>So I have no need to deal with any new boot parameters besides I already know <PotentialUser-96>Also, I know that I can add package definition with any git repo and use it like normal package in guix, am I right? <PotentialUser-96>Ah, more questions. Is there oneshot mode in shepherd (to execute script once at late boot for example)? And are there some security mechanisms in guix init system, like in systemd (isolation, capabilities and so on)? <Rutherther>Shepherd itself does not deal with isolation. There is least-authority-wrapper in guix, its not used by many of the default services, though. So again it needs manual work for already existing guix system services <PotentialUser-96>That sounds really nice. Guix at least gives me possibility to change some system parts, while other distributions do not. <Rutherther>Guix is entirely source based so you can change anything. But it can require a lot of knowledge and sometimes hacking around some assumptions <kestrelwx>Are the scopes of the package modules described somewhere? Or it's only inferred? <csantosb>Do we have a valid example of changelog in the update of a rust-apps package ? Thinking on #4535. <civodul>kestrelwx: hi! nope, itâs not described; in general people try to choose something that sounds reasonable, which is usually the right choice, and if not, discussions ensue <civodul>in short: do what sounds right to you <csantosb>look: thank you; I was mostly thinking about previous examples in git history <look>hopefully this will be more clear with #4623 <mwette>Re: gnu-store.mount on foreign, is this correct? gnu-store.mount makes the store read-only while guix-daemon starts up, and at some point guix-daemon umount's /gnu/store in order to expose the tree as rw (for guix-daemon or root). <civodul>this has been the topic of long discussions and several revisions, and i think it now works no? <civodul>/gnu/store must be writable at the time guix-daemon starts; after that it should be made read-only <mwette>Thanks civodul. Ah, right! I'm still reading up on systemd etc. Well, I created a filesystem mounted at /gnu/store, set up in /etc/fstab. It seems if there is a gnu-store.mount file under /etc/systemd/system then that filesystem is NOT mounted at boot time. (I currently have guix-daemon disabled.) <mwette>I was about to try adding `remount' to the options in gnu-store.mount and see if that works. <ieure>mwette, Sounds like a systemd issue. If your gnu-store.mount file looks correct, but the FS isn't mounting, the .mount is probably not linked from any `.wants' directory. <ieure>Systemd uses symlinks for this, ex. for "foo.target", all its dependencies are symlinks to systemd units in "foo.target.wants". <ieure>Guessing nothing wants the .mount, so systemd never does anything with it. <mwette>I think the issue is that /gnu/store needs to be mounted twice, implying two gnu-store.mount files. If I take gnu-store.mount away, /gnu/store is mounted on reboot, via /etc/fstab. <Rutherther>I think using /gnu as mount makes much more sense than /gnu/store. Gnu store is not much also without its state, located at /var/guix. For separate /gnu partitions/disks it is definitely better to bind mount from something like /gnu/var/guix so that the state is still together with the store. <mwette>Hmm. That seems restrictive. I'll peek. <Rutherther>I do not know what your use case for putting gnu store on a separate partition is, but the contents of the store are just 'random' files unless accompanied along with the state <mwette>It's a way to guarantee space. I don't do a lot of SA work now, but I did 30 years ago, so my methods may be outdated. <mwette>gdamjan on #systemd says: guix-daemon.service should really have RequiresMountsFor=/gnu/store <Rutherther>as civodul noted, guix-daemon has to start before gnu-store.mount. If you add that to requires, can it really start only after guix-daemon? <Rutherther>guix install script does enable the gnu-store.mount service. I do not think that guix-daemon should depend on it <Rutherther>is the gnu-store.mount service enabled on your system, and if not, what disabled it? <mwette>The issue is I can't have two systemd gnu-store.mount's. I have another option from #systemd. I will try that later. For now I moved everything so /gnu is the mount point. <podiki>Rutherther: will respond to the codeberg issue re: xorg-server updates when i get home, but ideally would add a commit to use the -for-tests variant in the culprit package (glad?) because xorg-server should have much fewer direct dependents by design <dragonknight_04>Anyone else have issues with a key file not being loaded after running "guix pull" and restarting? <Rutherther>or... what key file are you even talking about? when is it being loaded? <dragonknight_04>I have a keyfile for my luks encrypted partition loaded in initrd and then added to mapped-devices as an arguement <dragonknight_04>it works just fine after reconfiguring the system but after that it fails to open <FuncProgLinux>Does go-build-system change dependency versions at the go.mod file? <FuncProgLinux>Say if guix has go-github-com-fatih-structtag@1.2.0 but the go.mod file specifies go-github-com-fatih-structtag@1.1.0. Does the build system change that to match Guix's version or that needs a package derivation? <Rutherther>dragonknight_04: after what... after guix pull and restart? Guix pull has no effect on system stuff, so it's impossible that would be the cause <dragonknight_04>ah, sorry. I'll do some more troubleshooting with it later but at least I can rule out one issue <basicnpc>While developing guix in a per project basis, is there anyway to make the env jailed in some filesystem (like chroot)? <Rutherther>...wondering if we could do the computation of guix derivation offloadable. Or if we could use guile native to the system running the computation rather than the 'target system'