IRC channel logs
2026-11-04.log
back to list of logs
<simendsjo>I'm trying to understand why adding the eudev package to the inputs of xf86-video-amdgpu would solve hotplugging issues. Does the video driver try to dlopen any of the libraries of eudev to work? <ieure>simendsjo, Because udev is an optional dependency of the driver, whose configure script conditionally enables facilities depending on which libraries are available on the system, and adding it to the inputs makes it available. <ieure>Try it yourself: `tar xf $(guix build -S xf86-video-amdgpu)' && grep -ri udev xf86-video-amdgpu* <ruined>I'm relatively new here. Has there been any discussion around signing the 'latest' guix builds and/or providing checksums? <sneek>Welcome back apteryx, you have 1 message! <efraim>untrusem: the commit adjusting it makes it so that lookup-cargo-inputs is under define-cargo-inputs to try to decrease the indentation enough that it shouldn't move each time something is updated <sneek>efraim, you have 2 messages! <sneek>efraim, untrusem says: guix import -i <file> is doing a strange thing now, it is modifying the whole `(define-cargo-inputs lookup-cargo-inputs` procedure, not just adding the inputs for the package I am importing for <sneek>efraim, untrusem says: and its not for just a specific package. <efraim>sneek: later tell untrusem make sure you have a newer commit than the rust-team merge so you have a newer guix/read-print.scm so you get the expected indentation <yqshao>I was very grateful when I read how I can get my guix profile in a chroot environment >.< <graywolf>Is guix shell caching misbehaving for anyone else since recent update? <graywolf>The shell environment is often wrong and I have to rebuild it with --rebuild-cache. <graywolf>Why are we caching on manifest name? :-O <protvin>Currently I am research how to right package qemu-e2k. <protvin>jlicht: yes. I have succesfull seed bootstrap for hex0, hex1, hex2, first C compiler in progress <protvin>I tested that on qemu-e2k in my podman container. That working. <jlicht>awesome, I wish you lots of luck (or patience) <protvin>jlicht: currently I think to make qemu-e2k package definition <untrusem>sneek: later tell efraim: I am targetting the master with the latest commit <sneek>Welcome back untrusem, you have 1 message! <sneek>untrusem, efraim says: make sure you have a newer commit than the rust-team merge so you have a newer guix/read-print.scm so you get the expected indentation <efraim>untrusem: perhaps a difference between guix import ... and ./pre-inst-env guix import ...? depending on when you last ran guix pull? <sneek>efraim, untrusem says: I am targetting the master with the latest commit <efraim>sneek is going to get fat at this rate <untrusem>what I usually do with rust programs is that I pull the repos in a separate directory i.e `~/dump/sources/<package>` and use guix import from there <untrusem> guix shell rust:cargo -- guix import --insert=/home/untrusem/guix/gnu/packages/rust-crates.scm crate --lockfile=./Cargo.lock reka <efraim>after using guix shell ... to generate the new Cargo.lock and audit it I then switch back to my guix dir and run ./pre-inst-env guix import --insert=gnu/packages/rust-crates.scm crate -f /tmp/cryptography-44.0.0/Cargo.lock python-cryptography <efraim>guix import itself calls (guix read-print) to do the indentation <untrusem>I never used /pre-inst-env for importing crates, ohh well something changed <untrusem>efraim: I sometime see security cve after audit <untrusem>cause its not something we can fix in our package <efraim>honestly I don't think there's much we can do other than try to make sure the crates use the newest version they can <efraim>I have that attempt with #12087 to rewrite the crates to newer versions as we find vulnerabilities but it needs more work <Icy-Thought>say a package is in gnome-teams (example), how long does it take for it to land in master? <ieure>Icy-Thought, There really isn't a stock answer, it depends on what's going on in the branch and when the package was updated relative to when the branch was cut. <Icy-Thought>hmm... I am tbh confused to why the package was merged into gnome to begin with <ieure>Icy-Thought, I would say for large update stuff (GNOME, core-updates, some of the language-specific stuff), it's on the scale of weeks, but in some cases they've taken months. <ieure>If it's just a font, you can probably copy the package definition out and use it before it merges. <ieure>I've "forward-ported" stuff like that a few times. Very easy if you have a channel set up. <Icy-Thought>guess reasoning was because cantarell needed fixing, oh well <Icy-Thought>Makes sense ieure, I am somewhat not used to this workflow lol <Icy-Thought>lilyp: if you are awake and fine with answer, please help me understand what you meant by `you may want to limit it to those grammars that have an associated -ts-mode in the base package`. Because I translated it to ts-modes that emacs supports otb. But I could be wrong <illybytes>hey so, im in figurative hell rn (dealing with node) <illybytes>so im trying to package the tophat gnome extension <illybytes>but it uses typescript so it depends on gjsify/types <lilyp>yes, that's what I mean, if the `emacs` package itself has `something-ts-mode` then `tree-sitter-something` should be in your meta package <sneek>lilyp, apteryx says: thanks for the heads-up <illybytes>all the packages needed for tophat are under that repo <illybytes>is there a shortcut to mass compiling/bundling all packages under a repo? <lilyp>note: I haven't checked whether there is an exact or inexact match, I'm simply asking you to make sure it's an exact one :) <Icy-Thought>lilyp: ah then I understood, nice! Now here comes another question since I need help with this one... how does one make it so that we avoid installing a ts-mode package when there is another package that installs it. Example, neovim installs lua ts grammar, which is what we want to avoid for clashing <lilyp>You really don't. If it can be solved without propagation, the two can coexist. Otherwise, you need to rewrite one input. <lilyp>Well, the best outcome would be for emacs and neovim to agree on its tree-sitter-lua, then there is no conflict to be had :) <Icy-Thought>because one real issue that I have ran into (not related to ts), is being unable to install mpv while having lua installed because lua versions clash <lilyp>Well, preferably, you shouldn't install lua at profile level, but at the same time, mpv shouldn't propagate it. <lilyp>So it's both a package and user error 🫠<lilyp>For programming language, do make a habit of using `guix shell` to keep your setup local and clean :) <Icy-Thought>More like a modular system that I enable/disable stuff <Icy-Thought>(that's how I used to do it in nix and got very used to it after 6 years of use) <ieure>Icy-Thought, Write manifests, `guix shell -m lua.scm' to get a lua environment, or whatever. <ieure>Icy-Thought, It's declarative *and* adhoc. <Icy-Thought>guess i need to make a `guix load -m bla` and it loads manifest from my repo or something <ieure>Icy-Thought, I believe the Guix Cookbook has some stuff to hook into direnv so you get a profile activated when you cd into some dir. <Icy-Thought>I was thinking more in terms of being able to quickload instead of cp $DOTFILES_DIR/manifests/bla.scm <Icy-Thought>But yeah, I know what to do from now on... more manifests are needed <lilyp>You must construct additional manifests. <lilyp>'twas a joke based on your previous message and "You must construct additional pylons." <Icy-Thought>Got a couple more to write (bringing in a couple of fonts and whatnot) <Icy-Thought>I am just a guix baby and I am submitting PR's... *pats my own back* <lilyp>It's in `(guix build-system union)` and `(guix build union-build-system)` :) <untrusem>can you explain to me about the forward declarations thing you mentioned <Icy-Thought>mate... even rg "(guix build union-build-system)" fails in guix repo... what magic are you doing :S <Icy-Thought>No one listens to me anyways, so I may as well pretend someone does <lilyp>Icy-Thought: my bad, it's just union <lilyp>untrusem: it reads "ext:render/…-dyn.so", the render/ part is wrong <untrusem>should it matter here though, the package works fine, well I will ask the author <Icy-Thought>untrusem: last time I checked the .so file is compiled to the parent dir, not the render dir <Icy-Thought>I can only find a handful of examples for union... noen with deps dayum <tusharhero-xmpp>Icy-Thought: it doesn't matter if the was file doesn't exist. This is why never noticed this mistake. <cwebber>we should get it into guix with a guix home service and try to make it the primier guile desktop environment :> <cwebber>knowing jfred is using it is inspiring :)