IRC channel logs
2025-01-11.log
back to list of logs
<Hamled>I believe that issue is referring to the QEMU package itself, not necessarily the Guix image you can download from the website <lfam>And Hamled is correct, too <lfam>I mean that, as of that date, the package in question built reproducibly. But there could have been another regression since then <B-|>no i do not care about the package <B-|>i mean the guix image <lfam>Personally I don't know the answer <podiki>qtbase is what guix locate tells me on my machine <dcunit3d>is there any simple way to render the GNU or Guix .tex docs with syntax highlighting in the PDF's? <dcunit3d>like i know there's a make task in the guix project to generate the docs <dcunit3d>but is there a good way to shim something in, so syntax highlighting is provided when the code is rendered? <meaty>What's the canonical way to handle when a repo's source dir isn't in its root dir? <meaty>i.e. the "git clone" operation gives, e.g. package_name/files/src instead of package_name/src <the_tubular>guix system: error: `/gnu/store/5m6lhgm9hhi1k0hiqafsq815rc792bc4-guix-1.4.0-31.121e96d/bin/guix substitute' died unexpectedly <janneke>sneek: later tell lfam: reconfiguring the system with a fresh gnome fixes the .gsd-usb-protect segfaulting <janneke>sneek: later tell civodul: reconfiguring the system fixed offloading <janneke>oh, that raced, guess sneek was eating <ferocious_iguana>I was looking at upgrading Kitty Terminal package (packaged version 0.21.2 and current version 0.38.1) but it seems non-trivial to someone knew to Guix. The main program is written in C, but a bunch of submodules are in Go, so I will have to invoke a go build system alongside the gnu-build-system for the main program. Is that easily achievable? <Guillawme>I have no idea because I am also new to Guix, but I am also interested in an up-to-date kitty terminal so I hope you will manage to figure it out. Since it's already in the package collection, shouldn't it be as simple as updating the version number and hash and rebuilding? <ekaitz>ferocious_iguana: now they added go on top of the c+python mix they had? <ekaitz>ferocious_iguana: what you can do is include go as an input and run it yourself in a phase using (invoke "go"...) <ferocious_iguana>Yeah, sometime around v0.27 they introduced kittens written in Go - so it's not really a matter of bumping the version, changes needed to the package definition <Guillawme>Ah ok, this explains why it was stuck at this old version in Guix. I was wondering, but indeed this complicates the package definition. <Rutherther>go needs to go into native-inputs in this case, not inputs. Also, it won't work that easily, you will need to build directory with the dependencies - see setup-go-environment phase in go build system <the_tubular>I did `guix install zsh && guix remove zsh && guix gc somehow zsh is still in /gnu/store <janneke>the_tubular: guix gc --delete=<file-name> deletes it from the store <the_tubular>Cool, but if it did not delete after a guix gc, does that means it is still needed ? <janneke>guix install is a combination of guix build and creating a profile (with zsh in it) <janneke>guix remove removes it from the profile, but it's still built and available <janneke>it needs the full file name, yes /gnu/store/...-zsh-x.y.z <janneke>running guix install and guix remove creates new profile generations <janneke>doing something like guix package --profile=<the-profile> --list-generations show you the generations <the_tubular>Can something like that also works ? `guix package delete-generations` <the_tubular>I get `error: delete-generations: extraneous argument` <janneke>for guix package, it's --delete-generations=xxx <Kreijstal>is there a way to build a package phase by phase <the_tubular>ZSH is still in my store though, even after a guix gc <h4>When I try to use NVim plug-ins it complains about not finding executable, I guess because of lacking file hierarchy system, but if I try to run NVim into a compliant one, it doesn't even run, like abort, segmentation failure and so <janneke>Kreijstal: not really. you can use --keep-failed and then ^C at the right moment (or insert a stop/crash phase for the build to fail at the right stage) and then manually build the package <h4>When I `nvim` outside a container, it works right, but inside a container, it exits immediately, despite outputting normal interface to stdout <Kreijstal>janneke: when you debug like that do you make a shell with all inputs of the package you defined? <Rutherther>Kreijstal: you need to build the package and look through the produced paths <janneke>Kreijstal: look at the debugging page, it's the sourc environment-variables line <h4>All it prints into the container is ".[H.[J.]112004h.[?u.". Where outside the container it prints everything ".[?1049h.[t.[?1h.=.[]11;?..[?2..." <Kreijstal>Ahh, so if you wanted to implement a "which package gives me this .so" You'd have to compile all packages? <Rutherther>Kreijstal: yes, then you can use guix locate. There is currently no database built automatically <Rutherther>ideally you would get that database from the build farms <Kreijstal>I don't think I want to know how long it takes to compile ALL packages xd <Rutherther>well you would get them substituted if you use substitutes, so you don't have to compile it yourself. Of course the build farm compiles everything <h4>Apparently `. [H`: Move the cursor to the home position (top-left corner). `. [J`: Clear the screen from the cursor to the end. `112004h`: Likely setting a terminal mode. `. [?u.`: Probably related to cursor visibility or other terminal settings. <h4>But that doesn't help knowing why it exits <h4>You need to `--preserve='^TERM'` otherwise it doesn't know how to use the terminal ig <stochastic>Hi! I changed my password and my GNOME keyring (with all kinds of important information) doesn't unlock anymore. <stochastic>Does anything important happen in gnome-keyring-daemon while the password is changed? <dariqq>janneke: civodul also pushed my cmake changes to libgcrypt-gpg-update branch, not sure if they are needed for core-packages-team as well then? <janneke>dariqq: ah, well whichever branch is added to master first :) it doesn't really matter but thanks for the headsup <getstate>How do I build a package symbol defined in a module? I'm trying to do guix build -L 'pathToModule', but the symbol isn't defined. It only works if I refer to it in another module. <getstate>eg: when it's in my list of packages and I rebuild the system, the package builds. But guix build doesn't find it. <mightysands>Hi, I'm reading about guix for the first time and it seems pretty interesting as an OS. I'm a Slackware Linux user atm but am considering other OS's to use when I get a new RISC-V server. I like how Guix seems highly extensible and cutomisable to the user's needs while retaining simplicity, especially in its' init systems, but I was wondering about two things: 1. What's this I hear about guix requiring greater amounts of disk space than <mightysands>other package managers ? And how much more space is usually required on average ? 2. Does anyone here have any opinions on how guix compares to Slackware ? I'd love to hear some perspectives <Rutherther>mightysands: due to functional nature of guix package manager, every difference in a package or its dependencies leads to a new output path, and a completely new compilation. So every time there is an update, you get a new path. The old paths are not deleted automatically, you need to 1. remove their gc roots - ie. remove your older system generations, 2. run garbage collection. Now, if you make sure to always delete older generations and to always... <Rutherther>... use only one guix version (for your system, user/home, shells etc.), you may not need that much space. It all depends on your use case of guix. Still, since you need to be prepared for a world rebuild, you need at least one full system closure amount of space available for updates <mightysands>That's interesting. That reminds me how many Slackware users keep a copy of the complete source tree on their local machines for the sake of recompilation... <mightysands>Personally I don't do this because I need the extra space. <mightysands>But how many Gb on average would you say this full system closure takes up usually ? About double the amount used for installed packages ? <Rutherther>you don't need to compile software available from the guix channel as long as you use substitutes, and potentially wait for a bit after updates <Rutherther>mightysands: it depends on what sw you are using, so averaging over all users system closures doesn't make sense <mightysands>Is "substitutes" to say pre-compiled binaries distributed by the guix servers themselves ? <Rutherther>and no, it doesn't take 'double the amount used for installed packages'. If you installed all your packages via your system (and not stuff like guix install or guix home), it would take precisely the amount used for installed packages... <Rutherther>and it's not necessarily more than if you installed those packages on other distro <Rutherther>yes, substitutes are like caches. They build the packages and then if a package output path you are building, matches, it will get downloaded instead of compiled <mightysands>Thanks. I was mostly asking because the wikipedia article stressed at various points that guix requires higher amounts of disk space than other package managers <mightysands>I just realised that an advantage of guix would be that if all the variations of substitutes are uniquely hashed, then that would entail a great increase in speed while still maintaining robust security. That's rather cool <mightysands>Well, if I understand correctly, in a package manager such as APT on Debian, where pre-compiled binaries are the norm, if the server is compromsied then the binaries are too, whereas in guix, due to the unique nature of hashing every variation and derivative of a binary, then this would add some degree of extra security ? <mightysands>Actually, I might be jumping to conclusions there... <Rutherther>mightysands: the thing is that what is hashed are the inputs, not the outputs (for most packages, there are fixed output derivations, those are used for sources) <Rutherther>mightysands: you can imagine it sort of like: guix makes sort of a build script, with all paths hardcoded to correct paths to dependencies, and then hashes that. It's not exactly like that, but is probably what comes the closest without too many complexities <mightysands>I see, so it doesn't really offer much in the way of greater security, but it does offer greater efficiency <Rutherther>mightysands: I don't know what you mean by efficiency here <mightysands>I mean over the longterm, if one reinstalls a package but the inputs were the same as before <mightysands>it doesn't waste power and time recompiling if it can access a substitute <Rutherther>mightysands: right, but I wouldn't really call that efficient. On the contrary if I was doing sort of an 'assesment' of package managers, I would say guix is less efficient, because when you update, you need to either download everything new or compile it. You cannot do partial updates like you can with some package managers, where only differences from current version are sent. And this can be the case even if in the end nothing actually changed in... <Rutherther>... the produced output, but something like tar was updated, and it's used for extracting the source <mightysands>Oh, but then in this case, what would you say the advantages of guix are over other package management systems ? <Rutherther>mightysands: on the other hand guix offers other stuff - transactional updates (if something goes wrong, you go back easily - this of course doesn't include the state software saves), possibility to use transient shells without installing the sw permanently, possibility to compile sw against many different libraries, possibility to have multiple versions of one sw and switch between them, possibility to install stuff per-user, possibility to pack guix... <Rutherther>... software and then run it on other linux computers that don't use guix, then the whole reproducibility which may not be important for some people <mightysands>the ability to install software on a per-user basis definitely seems like a str <mightysands>It'd be good for my server, I think. I'm wanting to set it up for teaching computing to my friends/family <mightysands>the reproducibility, I'm not so worried about because I could do a similar thing by making compile scripts in bash. I've never really seen the use case for docker type systems other than laziness <mightysands>I've never heard of transient shells before. How do they work ? <Rutherther>it's quite simple in the end, you execute "guix shell <programs>" (or there are other means to specify the packages like via guile file), then it will just provide you the programs you want, and give you their env vars - at minimum PATH, but other stuff like LIBRARY_PATH if it's so libraries you will be compiling with etc. <mightysands>So that would allow me to write shell scripts which call uninstalled programs, and install them specifically for running the script ? <Rutherther>mightysands: not exactly install them as they aren't in your actual environment, just environment of the script, but yeah, you can even use guix shell as shebang <mightysands>Rutherther: Interesting. That adds a degree of convenience for the average sysadmin, but for a personal home machine it seems like an unnecessary luxury <mightysands>but maybe I'm just not being creative enough in thinking of use-cases <mightysands>Have you found this particular feature to be useful for your own purposes ? <Rutherther>yes, I use it all the time, I don't like polluting my environment with the programs I don't need, but use only for development on some projects. Also to test sw I would potentially use <mightysands>I wonder if this feature might be easily taken advantage of by malware... <janneke>nobody cares about reproducibility, until a software just won't run in another computer/environment <Kreijstal>what made me interested in guix was java and rust packages <omar_b>Any idea about where can I find information about building custom build systems and how they work <evan>quick question, why doesn't guix system come with the 'clear' command pre-installed? It can be written in one line of code and will add no extra bloat to the system to have it pre-installed <Rutherther>why would you type clear if you can do Ctrl-L :) ... but no, really, I don't know <evan>Ctrl-L does work, it's honestly just my muscle memory because I originally learned to use clear, so when I'm on autopilot mode I always type clear lol <evan>hm, I just learned that 'clear' and Ctrl-L do slightly different things, clear with no arguments clears the terminal scrollback also, but Ctrl-L doesn't do that. ctrl-L is the same as 'clear -x' <janneke>if you add ncurses to your system's packagses, then "guix comes with 'clear" preinstalled <evan>although on some other distros, 'clear' is present without ncurses installed, i.e. Fedora which I'm currently using <evan>also, somewhat not useful, but here is the source code that does the same thing as Ctrl-L: int main() { puts("\033[2J\033[H"); return 0; } <janneke>you can always add/present that "clear" package to guix <evan>sorry, I was wrong about clear not coming from ncurses in fedora <Kreijstal>I think I just wrote a way to inspect structs in guile <Kreijstal>I don't know why this isn't default behaviour <Kreijstal>is there a way to change the default ouput display of guix repl with my own function? <simendsjo>Anyone using v4l2loopback? I'm installing v4l2loopback-linux-module in my operating-system configuration, but lsmod still doesn't show it. Tried adding "v4l2loopback" in a kernel-module-loader-service-type, but still no luck. Any ideas? <ferocious_iguana>I tried installing Guix on bare metal, but booting from the USB stick results in an error message that I cannot read because the message is pushed to the far right of the screen and truncated by the screen edge. See screenshot: https://i.imgur.com/3xKXWLq.jpeg <simendsjo>ferocious_iguana: Try using the simplest possible display configuration. If you're on a laptop, no external screen. If you have an external screen, plug it in directly using a e.g. HDMI. <ferocious_iguana>hm, could be because I have dual GPU :) Let me unplug one, thanks for the suggestion! <simendsjo>Ref my kernel module loading issue mentioned above: the kernel module package has to be added to `kernel-loadable-modules`, not `packages`. Works fine now. <meaty>Is the "no binding `~A' in module ~A" error message functioning correctly? I get it often but I'm starting to wonder if that's actually what it's supposed to say <meaty>cos it's a completely uninformative error message, even with the stack trace <Rutherther>meaty: it should definitely have the binding and module somewhere next to it, this is just the format of the message <meaty>Rutherther: what if the message is always Throw to key `match-error' with args `("match" "no matching pattern" (unbound-variable "resolve-interface" "no binding `~A' in module ~A" (shared-mime-info (gnu packages freedesktop)) #f))'. <Rutherther>exactly, so the binding is shared-mime-info and the module is gnu packages freedesktop <meaty>Rutherther: but the package defs I add have no reference to shared-mime-info or freedesktop? <Rutherther>meaty: I am going to make a stretch here and guess you introduced a cyclic dependency in the modules then, most commonly introduced by use-module commencement <meaty>Rutherther: the only change I made from master is adding one package def with no inputs <Rutherther>okay, so I am also not sure how one is supposed to interpret the error message then. But what's unbound for your case is the "commit" used in commit field or git-reference <meaty>Rutherther: aha, thanks for catching. sorry to waste your time <meaty>do you think it's a bug that the system sends the same error report for all malformed packages? or is there something wrong with my system <Rutherther>meaty: it's just that the error message is higher, you should see "error: commit: unbound variable" <Rutherther>this throw to key is just notifying about the error, it doesn't seem to contain it fully <ekaitz>hi! how can I depend on code that is in a different channel (not guix itself) from my own? is that possible? <Rutherther>ekaitz: if you have a channel, you specify dependencies in its definition <dariqq>ekaitz: dependencies field in your .guix-channel <ekaitz>oh! i didn't know about that one <meaty>What's the right way to handle repos that keep their source directory a level deeper than the root dir? <meaty>i.e. the source dir is at package_name/package/src/ rather than package_name/src <dariqq>meaty: if all you need is to change the directory just add a phase that runs '(chdir "dir")' <ferocious_iguana>I now tried booting the guix installer from USB with two different graphics card and still didn't succeed. I tried on a laptop, and it doesn't boot, while Ubuntu image does <ferocious_iguana>I also tried images of a couple of downstream distributions of Guix, same problem <simendsjo>ferocious_iguana: At what point does it fail? If you have hardware incompatible with free software (e.g. requires non-free firmware), you might not get it working. There are unofficial channels to help with this, and I have to use it myself :/ <ferocious_iguana>I'm on a desktop computer with AMD CPU and AMD graphics (get the same error with NVIDIA too). I tried the image with non-free firmware and get the same error, so I assume it's upstream issue. <Rutherther>you might have to blacklist amdgpu, at least without non-free firmware <simendsjo>I have used the stock linux kernel with linux-firmware (and extra wifi drivers for some hardware). Tested both nvidia, amdgpu and intel. And both intel and amd cpus. Never seen anything like your image though. Can you share your configuration somewhere? <sleep_walker>hello folks! I'm preparing some new package definitions and I finally got to "perfect setup" as described in manual. It's much more convenient experience. I wonder, is there some nice way how to open build log from failed build from geiser-guile buffer? I'm copying it to clipboard and opening manually but I guess you have more comfortable way? <janneke>sleep_walker: M-x ffap on the log file in the compilation or shell buffer? <sleep_walker>Is it possible to install from guile repl into my personal profile? I verified the build but I'd like to verify function before making patch... (I guess I need effect of `,run-in-store`, but I can't find proper function...) <sleep_walker>I mean, apparently there is machinery to do changes in git and build it so my question seems to me natural - the other option is to have own channel and have my modifications there so it can be installed but it doesn't look like right approach now... <ekaitz>i just pushed to master and it didn't trigger a rebuild to check the commit, wasn't it like that before? <rekado>I'm getting tired working on the python-team branch <rekado>it is soon due to be merged and I've fixed a few hundred packages, but it's bound to lead to new breakage. <rekado>I can't judge if it breaks somebody's pet project. <rekado>I know ansible is broken on python-team, but I'm not going to fix that. <rekado>stuff from the wireservice module is also likely broken; there are also really outdated django things that I don't feel like working on. <rekado>I'd be happy if someone could help out on python-team. (I only just realized I'm not even officially on the python-team...) <ferocious_iguana>simendsjo: my desktop has MSI X570 motherboard, Ryzen 5800X CPU and radeon 6700X graphics card. I installed many different Linux distributions in the past, it's the first time that an ISO doesn't boot <lockbox____>Did you check for secure boot? Guix doesn't use the shim loader for secureboot like most distributions <Guest1>Should dbus and elogind services be in the system or home configuration? <Guest1>Ok thanks I think dbus is a requirement for elogind so it must be in system as well 