IRC channel logs
2023-12-24.log
back to list of logs
<podiki>otherwise you have to go to the logfile as shell hides it (I don't know of an option to show the same verbose output as build) <recj>but when I use guix build, packages->manifest is an unbound variable <recj>basically i am trying to use a guix environment in lieu of a requirements txt and the python environment tools <podiki>you are doing guix build -m your-manifest.scm? <recj>no, i was using -f. sorry <recj>ok, i am getting some descriptive error messages now! <podiki>yeah you want -m for "manifest" :) <podiki>yes, you'll get the full log output (and can still view the log file if you prefer) <recj>i never knew a python package would need so much rust stuff lol <podiki>well if it includes any rust I think it will be a lot of rust, from how things seem in rust-land <pastor>Hello. I want to use Godot but I would rather use the prebuilt binary offered <pastor> by the Godot fundation to not use a custom build. I made a package which <pastor> patches the binary's `rpath` with `patchelf`. Would it be safer to rely on <pastor> `LD_LIBRARY_PATH`? Both approaches seem to work fine. What would you reckon? <old>pastor: IIRC rpath is permanent for the binary as opposed to LD_LIBRARY_PATH which is dynamic <pastor>old: yeah. I know that. But since in Guix we have the `wrap-program` procedure. I can use both to make the package <pastor>Am I looking for troubles using patchelf? <qrpnxz>I updated bugs i talked about on Friday. Seems apr package bug from bad mirror is fixed. (guix pull seemed to process the package fine today) <Jaeme>How does one compile a rust program using `rust-cargo' and rust? <Jaeme>I keep getting "ld: cannot find -lrt: No such file or directory" when I try to compile any Rust program. <Jaeme>Figured out my problem. I was using cargo and not guix. <qrpnxz>guix pull has finally succeeded after like 12 hours. Whew! That was cool to reproduce all those packages <Kabouik>So how do we whitelist commands in /etc/sudoers for programs that are in /gnu/store, since /etc/sudoers requires full paths? I have tried using the /home/user/.guix-profile/bin/program path, but I guess /etc/sudoers still needs the realpath with the hash. Any ideas? <Kabouik>I've successfully used that for a program in my ~/.local/bin, but am having trouble for those installed from Guix and therefore with a hash in their path. <podiki>so then when you do a reconfigure it will get the absolute store paths to whatever you are adding to sudoers file (generated by reconfigure) <Kabouik>I mdid the first part last night using (sudoers-file (local-file "sudoers-custom")) but I don't understand how the second part works, I'll read the doc again tomorrow with a fresher brain <qrpnxz> $HOME/.config/guix/current/bin is ending up on my PATH, but i can't tell what is doing that... <cnx>do you use guix home? <efraim>qrpnxz: that path is from `guix pull` <tsmish>qrpnxz: /etc/profile/guix.sh puts it in PATH on my system <roran>podiki: is vkdt in big boy upstream yet, or what do we call this thing i'm thinking of <fnat>When producing a QCOW2 image with `guix system image` and then launching it with QEMU, is there anything I need to do for the VM to have a writeable filesystem? I copy the image to a writeable location and fix the permissions before launching it with QEMU <fnat>I have some notes-to-self re using `qemu-img` to resize the image and then `growpart` and `resize2fs` from within the running VM, but I was wondering if that step is really needed <fnat>My problem is being able to, say, guix-pulling from within the VM without getting a no-space-left-on-device error <jessej>I have a similar workflow as you @fnat. was thinking of writing a guix service that does the resize2fs part on startup. Also wondering if there is a better way for this <fnat>jessej: excellent, thanks for confirming that's your workflow too. I thought my notes were out-of-date not finding mention of this in the docs. <podiki>roran: vkdt I guess I haven't submitted it here, if that's what you mean. easy enough to do I just meant to make sure it is up to date and then do that <qrpnxz>tsmish, thanks yes. Found the source at /etc/profile.d/zzz-guix.sh <qrpnxz>i heard good things about guix being flexible with package versions such that we can pick what we want. Though I wonder if the dependency specification is sophisticated enough to allow a range of different congruent versions, and disallow the incompatible ones. <tsmish>qrpnxz: As far as guix is concerned each package depends only on concrete versions of other packages, it has no version ranges to speak of. You can however make something on top that does dependency resolution and generates/modifies package specifications programmatically, `guix import` does something like that. <tsmish>Well, dependency resolution kinda gets in the way of reproducibility unless you use something like Go's MVS. <qrpnxz>but i can understand some of the problems with ranges have. For example, reproducibility really wants just ONE version. Go language has a mechanism for having that one version "picked" even tho you are compatible with many. <qrpnxz>not sure what MVS stands for, but i think i get it <vagrantc>but different packages can have different versions of the same library (although ideally not) <qrpnxz>"minimal version selection"? Yes, great feature. <vagrantc>i think that is the flexibility you might have been hearing about <qrpnxz>i wonder how that could work with dynamic linking. IS there dynamic linking? <vagrantc>it is ... dynamic linking to a specific path, as i understand it <vagrantc>there effectively is no system-wide /lib direrctory ... each program builds with all the paths to all it's libraries explicitly <efraim>"dynamic linking to a static location" <vagrantc>it is what allows two incompatible libraries to be in use on the same system at the same time ... <qrpnxz>yes indeed. Amazing. Sounds a bit storage heavy. I suppose you guys try manually to have versions agree where possible? Or do you post somewhere common versions that maintainers can look at? <vagrantc>everything in guix proper is in a single git repository <vagrantc>so *typically* there is only one version for a library and everything linnks to it ... but if there is a reason to have multiple versions, some packages might explciitly depend on a different version <vagrantc>every time you update a library, everything that depends on that library is rebuilt ... so yeah, gets to be a bit heavy on storage space and many rebuilds <qrpnxz>ah yeah, because those packages would need to be updated to new version, triggering rebuild, even though it is dynamic <qrpnxz>haha, yea. ABI is not really in the radar if you always building xD <qrpnxz>I admire RedHat for their ABI compromises. You can really make a package for RedHat X and have it work for like 10 years with no rebuilding xD <vagrantc>guix and nix are fundamentally different ways to approach many problems ... with various tradeoffs <qrpnxz>as i was going, i remembered a touched nix a while back and was getting some deja vu. But I'm more excited for guix because: 1) GNU project, freedom-focused. 2) (Guile) Scheme, not random new language. <tsmish>guix also does way more in guile than nix does in it's own language. For example, init script in initrd is written in guile and is generated in guile, while nixos uses dracut. <tsmish>That said scheme is double-edged sword, you wouldn't know if you have syntax error until you execute the code (and if it involves gexp's it becomes even more problematic). Also I suppose that the reason `guix pull` takes a while is because it has to reinterpret parts of package definitions. <vagrantc>ACTION notes that the initrd misses a lot of functionality, such as kernel module dependency resolution ... <qrpnxz>Should be possible to write a program that all it does is parse scheme and tell you if it has syntax errors. I do something like that for a project I'm working on where I do "code as spec". <qrpnxz>Wrote a little lua parser and all it does is check for syntax errors. And I plan to write a little subset parser so that I can choose to only accept static expressions. Guile syntax is a bit more complicated, but should be pretty doable. <lilyp>you can start by counting parens :) <tsmish>'read' and 'macroexpand' will do the simple stuff. I was mostly referring to misspellings in variables, function names, missing extra parens in let, gexp expansion not quoting lists leading to "Wrong type to apply" error messages etc. That's much harder to do. <qrpnxz>i have little idea about gexp. They are not in the R7RS scheme standard that I know <tsmish>G-Expressions (gexp) are guix specific. They are a way to make derivations (think build instructions). They are described in guix documentation in section 8.12. What I described is just a thing that annoyed me immensely where ungexping a list leads to inserting that list into builder without quoting leading to builder-interpretator treating first element of list as a command and failing. This is mostly handled using '#$, but you have to know about it. <tsmish>basically, don't worry, that's just me ranting. Pointing out misspellings will be hard enough. <qrpnxz>apparently a special kind of quasiquote from Guile <nckx>It's sorta kinda like a quasi->unquote that brings along useful magic Guixy context. Not something a regular unquote could do. <qrpnxz>no, i am speaking in general language terms. Yes, this appears to be a custom guix quasiquote, but the custom quasiquote feature is a guile thing that is not present in r7rs scheme, which is what I'm concerned with when thinking about parsing and validating a scheme document <nckx># 'reader' syntax is indeed a Guile thing. <nckx>R7RS is a minimum, not a maximum. <nckx>But note that #~ is just syntactic sugar, it is not 'gexps'. The (gexp (ungexp foo)) functionality is pure standard Scheme. <nckx>*standards-compatible. Y'know what I mean.