IRC channel logs
2025-11-05.log
back to list of logs
<guixos>ok upon reboot I did manage to get to GRUB after putting in decryption password however in GRUB when booting Guix I have to put my decryption password again and it failed to boot seemingly due to missing drivers which I knew was a thing from the install media (although I did initially think my card was suuported intel avx200 or something I also <guixos>have a broadcom bcm960ng or something like that if anyone knows that is the one with free drivers I can switch to that tommorow) so I had to go back to grub and add iwlwifi to blocklist but then booting froze at bluetooth so I added some other stuff and "single" and nomodeset and now I am finally in Guix but for some reason it has the GNOME greeter <guixos>which is not what I expected as I initially chose XFCE and GNOME but when it failed the first time I tried just xfce which failed again then xfce again which "succeeded" i'm nixos-liveos or whatever my username was when I was in nixos's live boot installation media <sneek>apteryx, you have 1 message! <sneek>apteryx, yelninei says: Did you solve the issue with missing bunzip2? Should we just skip the elfutils tests in that case. <ieure>guixos, GDM is the default greeter no matter what DE you choose. <ieure>guixos, You have to enter the passphrase twice because /boot is encrypted on Guix; so you enter it once, to load Grub off the encrypted volume, then again for the kernel, after Grub loads it. <ieure>guixos, I've never experienced Guix failing to boot due to missing firmware blobs, the hardware just doesn't work. Surprised your system didn't boot at all. <apteryx>re cuirass and package properties; should be supported; from this NEWS entry dated 2021: *** Honor timeout and max-silent-time package properties <guixos>heres the installation error that makes me have to redownload packages multiple times until I manage to download all required packages without getting this error: guix substitute: error: TLS error in procedure handshake the TLS connection was non properly terminated <guixos>also I saw this line spammed a lot during the downlodaing packages phase sometimes taking up my whole display also it's the one that failed causing that error: substitute: updating substitutes from https://ci.guix.gnu.org just in case this is unknown but it seems I have an outdated installation media or something looking at <guixos>ieure thanks that explains things, do you know what I can do now that I am in guix to be able to boot from GRUB without adding nomodeset single no?somethin i forgot? and adding iwlwifi,btintel,bt??,i??? to the entry which doesn't save and I don't remember what I put <ieure>guixos, TLS errors are ... uh, nobody seems to know, really. My theory is that whatever Guile TLS stuff we're using is buggy. <ieure>guixos, You'd need to add those to the kernel-arguments field of the operating-system record declaring your system's configuration, then reconfigure your system. <guixos>ok thanks a lot and good night it's 45 until midnight for me <padtole>a better way to bring inputs in to the environment of a snippet gexp than #~(begin #$(dependency-1) #$(dependency-2) ...) ? <apteryx>padtole: You probably shouldn't do that and use a phase instead; snippets are not delayed fields, and referring to top-level variables like packages is bound to introduce module cyclic dependencies <apteryx>padtole: for some reading on that, see (info "(guix) Cyclic Module Dependencies") <apteryx>which packages do we carry in Guix that use a binary seed to bootstrap themselves? I seem to recall we had one or two... <lilyp>not sure about binary seeds, but vala uses generated C code <apteryx>lilyp: I see. pharo-vm also bootstraps itself from generated C sources. <apteryx>but I meant a real, inscrutable binary. I thought we had examples of this still. If not, the better, though. <freshinstall>I am same person from yesterday (guixos, and nixos-liveboot) to succesfully boot into my fresh install apart from things I already mention I also had to add these kernel paramaters: blacklist: iwlwifi,btintel single nomodeset I'm not knowledgeable enough to know what those mean but just thought I would share in case it helps improve the installer <freshinstall>Also I figured out the name of my other wifi card it's: Broadcom BCM94360NG how can I check if it has libre firmware available without swapping it in <freshinstall>also my current wifi card is Intel ax200 which I thought does have open source drivers? <kestrelwx>Open source doesn't really mean it'd be available. Since it could require firmware blobs. Although, I don't know the details for the specific card. <freshinstall>(use-modules (gnu packages kde-graphics)) I keep needing to add lines like this, am I adding packages to my config.scm incorrectly? <freshinstall> (packages (append (list (specification->package "nss-certs") <freshinstall>hint: Consider installing the `glibc-locales' package and defining `GUIX_LOCPATH', along these <freshinstall>See the "Application Setup" section in the manual, for more info. <kestrelwx>freshinstall: Use a paste service like the one in the channel header for multi-line snippets. <kestrelwx>You need to include package modules in order to make their exported variables(i.e packages) available in the current scope. <Gnewbie25>guix install ungoogled-chromium says it's installing 140, but now that it's installed it's version 107 <kestrelwx>I'm on 140, so something in your path clobbers it. <Gnewbie25>im sending it but it's being filtered or something <efraim>not officially, but I have a package and service for it <Rutherther>Gnewbie25: do you have chromium in your system profile as well - did you make sure to `hash chromium` to pick up the new chromium and not the one in system profile? <Rutherther>Just run `hash chromium` and then try running `chromium` again. Also I hope you have closed chromium completely (all windows) to ensure it doesnt just communicate with the old version <kestrelwx>Rutherther: Doesn't it get set by `/etc/profile`? Assuming the profile already existed. <Rutherther>kestrelwx: It gets set inside of /etc/profile and unset at the end, as it should be <ganoob>it didn't work, but it's ok I'm just gonig to reinstall I only installed it yesterday and chromium is the only software i've installed so far it's no big deal <Rutherther>That doesnt matter, its a shell var, not an env var, yeah. Still it would be set in your shell if /etc/profile didnt unset it explicitely <kestrelwx>I guess it's that I almost never have any packages installed with `guix package` so I have to source it after `guix install` usually. <ManhattanArboris>run with `guix shell -v3 --container --development --file=python-pyqt-pdf.scm -K', the fix to pyqt works (I can open python and run `from PyQt6 import QtPdf` successfully), but I can't get frescobaldi to open for testing the container. <apteryx>ManhattanArboris: you'd have to share some environment variables/directories from your host to be able to display a UI from the container <apteryx>such as the DISPLAY or WAYLAND_DISPLAY environment variables, etc. <apteryx>it's easier to test from a guix shell --pure (or without --pure) <ManhattanArboris>apteryx: Thanks. Looks like it works without --container (it would not run with --pure). <apteryx>there may be containerized examples in the manual that could help <apteryx>there's one but for X11 in (info "(guix) Invoking guix shell") <ManhattanArboris>When launched from guix shell, frescobaldi now crashes instantly, reporting that it can't find libportmidi.so.2, even though portmidi-2 is an input of frescobaldi and it launches and runs fine outside of the shell. Curious. <cbaines>apteryx, sometimes I strace -f -p the guix-daemon, then start a build <apteryx>I ddn't have luck with the ChildPID or SessionPID or ClientPID reported by 'guix processes' <apteryx>I did have luck running 'pgrep guile' and grabbing the highest of the new PIDs. <apteryx>Shouldn't stracing ChildPID accomplish the same? <cbaines>I don't know if strace attaches (or can attach) to child processes <cbaines>stracing the guix-daemon with -f (--follow-forks) works because when the daemon and the builder forks, then strace follows them <apteryx>I didn't see all the various things the child is supposed to do, such as fork+execing hundreds of new processes while compiling. I was using building libinput and attaching with: sudo strace -p $(guix processes | recsel -e "ClientCommand ~ 'libinput-minimal'" -P ChildPID) -s200 -f -o /tmp/libinput-minimal-child.strace"" <cbaines>unless you do that very quickly before the builder has started running things, strace is not going to be following the forks <apteryx>why not? I put a sleep in a phase, so that I can attach during that time. <cbaines>because follow forks doesn't follow already forked processes <apteryx>nope, that "follow forks with output into separate files" <apteryx>I guess sysdig would have been useful here. Too bad it's broken at the moment. <apteryx>it reports "Initialization issues during scap_init" <cbaines>ChildPID seems right, although that can appear multiple times for a single build <apteryx>cbaines: so my trick of 'pgrep guile' and attaching manually is a workaround. It feels odd that I have better success with this than from using 'guix processes' <cbaines>maybe you ended up strace'ing the wrong ChildPID? <apteryx>Tat's what I get while libinput-minimal is being built <apteryx>and then If I attach strace to that you'll see the kind of output you saw in my earlier child strace link. <cbaines>I'm no strace expert, but your approach seems fine <apteryx>I suppose it happens because of my newly added mmap/munmap, and then the double munmap risk *can* lead to crashes after all. <apteryx>I had assumed this could be safe earlier, not having seen it cause problems in practice... yet. <apteryx>and when I hook strace to the PID, it doesn't reproduce of course ;-) <yelninei>what is the best way to xfail tests with autotools when the package defines some xfail tests by itself <RavenJoad>Are there any major Zig packages/tools/programs in Guix right now? I am working to package ghostty and am currently fighting Zig's dependency-fetching system. I want to make sure I'm not duplicating effort. <ieure>RavenJoad, There's a zig-build-system. <identity>RavenJoad: nothing more than zig-build-system at this moment. thank you for trying to package ghostty, i was planning to do that myself later <look>If looking to contribute ghostty to guix, then its more complicated, you'd need to package all zig dependencies manually <look>That combined with the custom build phase (which you can find on the ghostty package definition) it makes really easy to package any zig app from source for personal use <RavenJoad>look: I was aiming to contribute ghostty to Guix upstream. It seems like we will need to take the Go approach. I already got a toy working. I can get to compiling ghostty. Compilation falls over in a format string. <look>Yea, for contributing its a bit pain indeed, you need to do every dependency separately from scratch as any other package, we don't have an importer yet. Doesn't help that ghostty uses some unconventional dependency sources too <look>RavenJoad: If you wanna open a WIP PR on guix for it we can discuss further some specific issues, would also help to direct other people into helping towards it. I'd really like to have it on guix too <RavenJoad>On top of that, Zig expects their downloaded packages to be named with their hash in the download cache. <padtole>guix: i am popping in very briefly to share my idea somewhere. i am sure the discussion is old. it could seem nice if guix store paths were content-hashed as well as input-hashed, this could make many things clearer and allow for cyclic build trees. given that graft rewriting is already implemented, what might be required would be to rewrite a temporary output path to the final store path containing <padtole>its own hash, and not include these string offsets in that hash. curious if this has been discussed before. <ieure>padtole, This would completely break substitutes, since it's impossible to know the hash you need unless you have the content to hash, and if you have the content already, you don't need a substitute. <ieure>padtole, Also, many toolchains produce nondeterministic output, which undermines the whole point of such a thing. <padtole>(1) substitutes could keep using the input hash. (2) you could also put the content hash in the repo. <mononoke>I am trying to troubleshoot a failed system reconfigure and I'm stumped, if anyone might know what this means: `guix system: error: no target of type 'system' for service 'activate'` ... <ieure>padtole, You should ask on guix-dev, I'm sure someone can point you to previous discussions. But I don't think your idea is workable without significantly undermining the usability of the whole system. <padtole>maybe it's too similar to software piracy :P <padtole>the things that succeed nowadays are the things that don't use immutable content-hashed stores <padtole>by guix-dev, do you mean mailing list? <padtole>on the contrary regarding usability, this would prevent the current dance of constantly rebuilding idempotent packages. it would increase the usability <ieure>padtole, Including the hash in the repo would mean that you have to build the package on every supported architecture *natively*. The output varies per arch, so it's can't be "the hash of the package output," it has to be "the hash of the output for a particular target architecture and toolchain, and possibly cross-build source architecture arch as well." <ieure>It would make maintaining packages impossible, or force dropping all but one arch. <ieure>padtole, What do you mean by "the current dance of constantly rebuilding idempotent packages?" <padtole>i'm trying to figure out how to view ravenjoad's pr and have to leave soon <padtole>but right now the build servers and source-based hosts keep rebuilding identical outputs which are then deduplicated when added to the store; this is because whenever any input path changes (such as the guix reivision), the hash changes, and must be rebuilt <padtole>it sounds like cross-compilers are not deterministic with native compilers yet? determinism is a huge project <ieure>padtole, The outputs are not identical when the inputs change. <look>RavenJoad: thanks! will take a look whenever I have some more --procrastination-- free time <padtole>ieure this is usually false, e.g. if i change the name of my patch the input hash changes but the output is identical <ieure>padtole, The output may happen to be identical in limited circumstances, but you cannot extrapolate that it always is, and it usually is not. <padtole>i dunno why you are saying this, whenever any build tool is upgraded its name changes changing every downstream package, even if it produces identical output <ieure>I'm saying it because it's true. The output is not identical, and there is no way to predict or guarantee whether it will be. <padtole>i apologize profusely if content hashes appear similar to media piracy <padtole>sed clearly gives identical output when upgraded <ieure>I have absolutely no idea why you keep mentioning piracy. <padtole>i have absolutely no idea why you keep claiming all these outputs differ <yelninei>how do you know that it behaves exactly the same? There could be a regression in the package and e.g. --version will report he new version <ieure>padtole, Because, again, it is true. <ieure>padtole, Please run the following command: `guix shell gcc-toolchain -- ldd $(which sed)' <padtole>what is true, is that you are spending a ton of energy arguing against an idea that would open up options in implementation here, and neither of us are devs <ieure>padtole, You will see store paths in the output, because the ELF table inside the sed binary has exact store paths for any library it's linked again. If any of those inputs change, sed is rebuilt, and the rpath now points to the hash of the updated input, even though the `sed' package has not changed at all. <padtole>you're most recent point, doesn't it support my view? <ieure>I have no idea why you'd think that. <padtole>well if the inputs change less, then sed is rebuilt less <padtole>if the inputs have the same paths when they are built identically, sed doesn't need to be rebuilt <ieure>padtole, I encourage you to ask on guix-devel, but as I've said, your approach has significant challenges and is not as easy as you think. <ieure>Also, not rebuilding sed if a patch changes is not a thing we want. What if the patch is bad? <padtole>anyway i was assuming lots of people wanted to do that, but it was hard to discuss and plan how <padtole>i think adding the idea of content hashes that exclude one's own store path would reduce the barriers <padtole>i understand the chat is not the place <padtole>eris looks nice but i think is a different idea more related to storage backends <kestrelwx>That's true. I focused on introducing a hash part of the proposal. <dthompson>ieure is right. you cannot prove in general that a build is "the same" if the inputs differ, hence why things are the way they are. it's the whole point of functional package management. <civodul>look: re zig2guix, would be nice to have that in ‘guix import’! <old>does someone has a complete system example with lightdm? I'm not sure how I am suppose to change from GDM my configuration <old>ehh nvm I think I got it <abc123>is there a guide to set up tailscale? <old>But I would like to see a configuration with tigervnc if someone has <rkazak>just want make sure I understand correctly, each user on a guix system has their own variant of the guix command, and also I guess the configuration files? <Rutherther>rkazak: typically, yes... "guix pull" is producing variant for a specific user, always <ieure>Yes, this is a typical setup, though not the only way to do things. <rkazak>thank you both. So how does this affect the Guix System base configuration? Is that owned managed by my personal account such that the "root" account is out of the picture? or is the "root" account still the owner of the base system? I am asking as I also want to understand the implications of using the "reconfigure" action after a "guix pull" <sham1>Well, your operating-system config file can be owned by a regular user <Rutherther>rkazak: it depends on what guix variant you decided to use, ie. what account you decided to use for the reconfigure. When you do sudo, still guix is taken out of your original PATH. I don't know what you mean by being 'owner of the base system'. And no, root account is not 'out of the picture', root account is the only account actually capable of doing reconfigure as it writes to files owned by root <rkazak>I see, so when doing a reconfiguration why would I not use root ( via the "sudo -i") ? <sham1>Well, if you use your user's guix binary, then that'll contain all the user's channels and package definitions and so on. Corrolary being that the guix binary of the root probably doesn't have that <neox>Hey there. Does anyone know if it's possible to give `gnome-desktop-configuration` an inferior in `shell`? If I give a list containing only packages, reconfigure works, but when I provide a `(first (lookup-inferior-packages package-inferior ...))` instead of a package name it tells me I got an invalid value <apoorv569>The zrythm package is really out of date. v1 has been released in Nov 2024.. and the package in guix is still some beta version. <ieure>apoorv569, Check open PRs and the issue tracker. <Deltafire>apteryx / ekaitz: did you get anywhere with IceDove? <ekaitz>Deltafire: do you want to help or you are just interested on the progress? <Deltafire>"Most of the timezone related failures are probably attributable to our use of a system-provided icu4c library instead of the bundled one." <ekaitz>Deltafire: where did you find that line? <ekaitz>oh yeah that's similar to the thing I tried to debug <ekaitz>i'm sure that's related with the tzdata thingie somehow <ekaitz>probably we just need to upgrade the icu4c? <ekaitz>oh I think I already tried that! <ekaitz>ACTION has too many things in mind and trying blindly doens't feel good <Deltafire>looks like they're both on 77 - well, the latest firefox is anyway <Deltafire>it does apply a bunch of patches to the bundled version <Deltafire>i guess removing the "--with-system-icu" config setting would determine whether it's due to the unbundling <Deltafire>but will probably take 2 days to recompile everything <ekaitz>Deltafire: do you want to give it a go? <Deltafire>updating to a newer version might also fix it <ekaitz>remove that line, remove the dependency to make sure and ./pre-inst-env guix build icedove <ekaitz>let's make that first if you can, and then we can check what's the difference between both libs <ekaitz>and find which is supposed to be the proper version of it <ekaitz>Deltafire: i'm in Central EU time, so I won't be awake when it finishes <Deltafire>heh, me neigher - unless it's sometime tomorrow.. <ekaitz>but I'll be happy to get a report tomorrow in the morning <sys-service-ques>Hi all, I asked a short time ago about autossh service failing at boot.After some analyzing it was clear that network not being ready was the reason. Simple respawn settings did not help . Made a pseudo copy of the original of the austossh-service-type code in gnu/services/ssh.scm and worked around via a simple service one-shot service sleeping 30 <sys-service-ques>seconds before autossh-starts. Wondering if there is a predefined service type somewhere checking for network connectivity given i could utilize instead of the simple wait...is there? <ieure>sys-service-ques, Yes, autossh should be requiring 'networking to start. <ieure>sys-service-ques, This is a common need, there's tons of prior art in the Guix repo. Really seems like a bug that a network-dependent service wouldn't wait for the network to be available. <ieure>But also, I don't know what autossh does, so maybe there is a reason. <sys-service-ques>restart if it breaks. If no networking is available at service start(like at boot) it is permanently unable to work correctly until manually restarted. That was my Problem <ieure>Sounds like a couple bugs there! <ieure>Odd that a system service would use a user's SSH keys IMO. <sys-service-ques>I simply modified the requirement to have have my sleep-service(requirement '(user-processes network-ready)) with 30secs in it in addition. That works and i would even call it ok-ish elegant-ish as it is straight forward but not the right thing ... <ieure>I'd remove the wait entirely and use the requirement ordering to guarantee that it only starts once there's network. <ieure>But also, if autossh gets wedged and stops working in situations where networking is broken, this *will* recur later. <ieure>So there's also a bug there, could be an upstream issue or might be the Guix service missing some flag to make it not do that. <sys-service-ques>well...it's intentional and i sue the connection defined in ~/.ssh/config all the time for my purposes. But i also need it there soon after logging in as i need a vnc tunnel because i'm to lazy to switch my Keyboard manually to my other linux system and simply start the youtube videos that way... <ieure>Just to be clear, this is an "I also have numerous important pieces of my life held together with this same flavor of hacker duct tape"-flavored laugh. <ieure>I have a CI/CD pipeline to share my calendar with my family, which traverses at least four machines end-to-end. <ieure>So like, no shade from me, is what I'm saying. <ieure>sys-service-ques, If you only need it after login, it might work better as a home service. <sys-service-ques>It's what people do. Why i have to do stuff professionally at my job i model all my privte stuff after how i would do it manually... <ieure>Yes, knowing how to do things the wrong way tends to take you far in the corporate world. The Sadness is when you also know how to do it right, but can't. <sys-service-ques>| If you only need it after login, it might work better as a home service. <sys-service-ques>True...i modelled the current solution after the original code with a few adaptions. Still have to learn a lot in regards to guix and scheme <sys-service-ques>| knowing how to do things the wrong way tends to take you far in the corporate world. <sys-service-ques>You can not escape it, you have a Boss. Even if you yourself can escape your own stupidities you cannot escape other peoples <pomel0_>what's the equivalent to the `build-essentials` package in debian for guix? <pomel0_>or, if there isn't, which package in guix includes `c99` ?