IRC channel logs
2026-02-06.log
back to list of logs
<pull-logout>hi what could it be that when i do a guix pull i got kicked out from the session and the guix pull procees is killed also? <mange>Could you be running out of memory? <mange>I'm not sure how memory hungry a pull is... <charlesroelli>Good morning. I need to run "sudo ip -6 route add default via fe80::1 dev eth0" on a guix system VPS hosted at Hetzner to get IPv6 connectivity. How do I add that to the guix system configuration so it's done automatically? <futurile>csantosb: morning, how you going, working on anything fun? <noe>charlesroelli, maybe look into static-networking-service-type? <noe>You can get more info about it in the manual <csantosb>futurile, manipulating and building gateware dependencies with Guix <csantosb>Not sure this falls into the fun category, though š„“ <futurile>csantosb: ah I see, bet that's complicated, specialist, hardware<->software licensing <csantosb>Not that much, ... just need to use the right tools <Kabouik>Is there anyone here using KDE Plasma as their desktop on a foreign distro? I don't (Sway on Guix system) and I have trouble solving the desktop integration issues my intern is having with guix-installed packages. None of them are listed in her DE's app launcher, despite ~/.bash_profile containing the lines to load the main profile. Her ~/.bashrc also contains lines to load her Guix extra profiles (but we may not keep them on the longer term, we'll <ekaitz>did we publish a blog post with all the Guix-related talks? <Kabouik>Also somehow, even after a guix pull, she seems to be getting outdated versions of the packages (i.e., direnv 2.32.x instead of 2.37.x, which seems to cause issues). I think this might be related to her main Guix profile not loading properly. <ekaitz>cwebber: about your email, what does the mnt reform use by default? uboot? maybe we can do that <ekaitz>now i'm reading in guix we actually use uboot... but how is that we cannot choose generations? I uboot *can* have a menu <cdegroot>Kabouik: a lot depends I think on the desktop manager that launches the session. I've done "Guix-managed desktop on foreign distro" (not KDE, but XFCE, but the story is the same) and ended up copying and heavily modding the bundled xinitrc as a copy in my home directory, and pointing the desktop manager at that. That's the right point, I feel, to do a lot of setup; I'm not even sure that the display manager -> desktop environment <Kabouik>This might be a little different from XFCE then cdegroot because I think she's using the Wayland variant of Plasma. I'm surprised that there is no more documentation on desktop integration for foreign distros, this sounds like a significant barrier to adoption. <cdegroot>Just replace the legacy distro with Guix, problem solved ;-). But the wider problem, I think, is that everything Linux desktop is heavily underdocumented. Or at least the documentation is like an oil spot: widely spread out and very thin. But yeah, no clue how Wayland works, I've never used it. I guess startup would be somewhat similarly convoluted and solutions would be somewhat the same. <charlesroelli>Kabouik: I had the same problem on GNOME with Ubuntu: the packages I installed with guix did not show up in the app launcher. The fix was to set up the packages in a guix home environment instead. That environment gets sourced by GNOME (maybe through ~/.profile ?), which now shows the home-installed packages in the app launcher. <Kabouik>cdegroot: I would love that but (1) my intern never used Linux before so Debian is a little bit easier to explain before going deep in Guix (the opposite could be argued, though, maybe it's easier to break paradigms before you've gotten used to them) and (2) getting Guix system installed on our machines is not straightforward with our IT department. :< <Kabouik>charlesroelli: that's bad news for me, I've never used Guix home <Kabouik>I will borrow the Debian + Guix + KDE laptop for the week-end and see if I can find what is missing. It would be okay to just launch programs from CLI anyway without DE integration, we don't care much about that, but I'm afraid it's cascading into other issues I mentioned above, that impedes our reproducibility objectives (basically direnv installed from guix being outdated despite a guix pull, sending warnings that it created a guix shell with 0 <Kabouik>packages despite a clearly valid manifest.scm; while a manual `guix shell -m manifest.scm` produces no such issue). <charlesroelli>I'm new to guix home as well, since last month. Already a big fan :) <charlesroelli>"guix pull" just updates Guix itself if I recall, afterwards you can update your packages with e.g. "guix package -u" <cdegroot>I use Guix home on Guix system and it's pretty simple to setup. I use it in a very restricted way though, most of my config still comes from files I put into their right spots from my dotfiles repo using stow. The end result is that it allows me to run my home env on other systems, like NixOS (which I use for work). <cdegroot>The tl&dr is that if you have a Guix system setup, doing a Guix home setup is pretty straightforward. <cdegroot>User-level shepherd gets started from your profile (IIRC), that's a bit of a gotcha, but it'll work. <PotentialUser-76>i dont understand what the `compose` macro in, say, `((compose (transformation-foo) (transformation-bar)) os-baz)` means <PotentialUser-76>please excuse me if this is a silly question; im inexperienced with programming in general <ieure>PotentialUser-76, Compose is a procedure which takes any number of functions and returns one function which calls them in order, ex (compose a b) returns a function which performs (a (b args)) <ieure>PotentialUser-76, See section 6.7.6 of the Guile manual for a more exhaustive description. <ieure>In the case of transformation functions, it chains them together, so instead of having to write deeply nested (transformation-foo (transformation-bar (operating-system ...))), you can (define xf (compose transformation-foo transformation-bar)) (xf operating-system) <ieure>In your example, transformation-foo and -bar are functions which return transformers, not transformers themselves, so you have to call them and compose the results. <untrusem>I wanted to debug a error my channel is having <ieure>untrusem, No, system service only. <ieure>PotentialUser-76, You're very welcome. <untrusem>wanted to debug this, I might have solved this, but I won't know if it will be successfull until next ci check <ieure>untrusem, You should be able to reproduce locally with: guix pull --url=/path/to/your/checkout --profile=/tmp/guix.master --disable-authentication <ieure>(Stolen from pull_request_template.md in the Guix repo) <ieure>..I believe you need to have the changes committed for that to work. <ieure>untrusem, I think this is your actual issue: rain-and-roses/packages/rust-crates.scm:21:11: warning: possibly unbound variable `warning' <ieure>It's a warning from the compilation, but the exception at the bottom is the same message, but an error, <ieure>untrusem, Not sure. It looks like the issue is a missing use-module for (guix diagnostics) -- that's what defines `warning', and is imported by (guix build-system cargo), which is where you got `rain-and-roses-cargo-inputs' from. <untrusem>cool I will just use a different method for cargo-inputs <ieure>untrusem, Can you build your oniux package locally? <ieure>untrusem, Yeah, okay so. The `inputs' field of package is thunked, so compiling the code doesn't cause the issue, but building the package ought to. <sneek>Welcome back coopi, you have 1 message! <sneek>coopi, PurpleSym says: `guix environment --ad-hoc -C --no-cwd python-notebook -N -- jupyter notebook` works fine for me, but Iām using it on a foreign system. <untrusem>but i pushed it regarding, I am abusin the ci š <untrusem>ieure, I imported a guix-1.91 nar form rustyguix but if I try to build oniux it tries to build rust-1.91 <ieure>untrusem, Different derivations, most likely. Why not add the rustyguix channel and import the package definition from there? <untrusem>or just copy their derivations, I don't like to add channels, I want to avoid guix pull as much I can <untrusem>someone had problems with running librewolf in guix ieure <ieure>@ieure@retro.social if you want to tag me. <untrusem>I should tell them to join this or create a codeberg issue <ieure>Yeah, filing an issue would be best. <untrusem>> @ieure@retro.social if you want to tag me. <untrusem>> Yeah, okay so. The `inputs' field of package is thunked, so compiling the code doesn't cause the issue, but building the package ought to. <untrusem>what do you mean? I used them after reading the cookbook <ieure>untrusem, Evaluation of the value of the inputs field is deferred until it's accessed. That doesn't happen at compile time, so `guix pull' won't surface the error. Either Cuirass is looking at inputs, or trying to build the package, that calls the procedure, the procedures tries to emit a warning, but the missing import means the `warning' symbol is unbound, so you get an error. <ieure>You should be able to replicate by loading the package and running (package-inputs oniux) in your REPL. Or just evaluating the form you put in the field. <ieure>So you probably have two issues, one is the missing module, the other is whatever's making `rain-and-roses-cargo-inputs' warn in the first place. <untrusem>cool, I also found out some other mistakes <rustyguix>untrusem: let me know if I can be of any help. I have been using rust 1.91-1.93, and it works so far. <rustyguix>I wrote Hako, to ask to join ci.guix.moe, to add a channel there. <ieure>Nice, I should get my channel in there as well. <ieure>I run Cuirass and substitutes myself, but it's not exposed to the internet. <ieure>Is "intranet" still a thing? If that's still a thing, that's what I've got. <ieure>I have some good stuff in there, but it's mostly unredistributable or so niche that I expect a maximum of, on average, 0.25 other humans on Earth would find it interesting. <ieure>But if you crave tools for working with filesystems for the decades-obsolete Microware OS-9 lightweight embedded realtime OS, I've got 'em <old>How much time it takes you to fork Guix on Codeberg? I've been at it for 10 minutes now .. <csantosb>Instead of forking, you may use the AGit Flow, which is way lighter and much faster <untrusem>> untrusem: let me know if I can be of any help. I have been using rust 1.91-1.93, and it works so far. <FuncProgLinux>old: Fork it not much on codeberg. Doing git clone does take ages lol <old>csantosb: sounds interresting <untrusem>old if you use emacs and magit, you can install emacs-agitjo package to help with agit workflow <csantosb>Waiting for forge to support Forgejo instances ... <untrusem>rustyguix can you share your rust-1.91 nar for your channel's rust.scm file <kestrelwx>Is my daemon old or does `guix build hello --timeout=1 --check` show `%2%` instead of the correct number of seconds? <untrusem>nevermind I have the rust-1.91 substitute but its still building rust-1.91 bulid building oniux <ieure>untrusem, Are you using a copy/pasted package definition, or rustyguix's channel? <untrusem>yep I am using the defination of the substitute I am having <ieure>untrusem, Link just says it's expired. <grm>Hi! My current laptop requires higher versions of alsa-lib, alsa-ucm-conf and alsa-topology-conf. I made a branch with the required changes. I would like to push these changes. Regarding the number of packages depending on alsa-lib, the build process requires quite some time (several hours on my laptop). In this case, is it better to propose grafts or to bump package versions and wait for build farms to provide substitutes? <ieure>grm, No, do not use grafts for this. <ieure>grm, See the "Managing Patches and Branches" part of the Guix manual (under Contributing). You need to see how many packages those updates will cause to rebuild, and if it's >300, we'll need QA to build your branch before merge. <ieure>untrusem, Hmmm, yeah, seems odd that it'd rebuild if you build a package needing it. <grm>ieure: perfect, I'll submit something soon, thanks!