IRC channel logs
2024-03-22.log
back to list of logs
<civodul>rekado: oh, love that web site name :-) <civodul>sturm: that suggests that the .drv file is truncated, perhaps due to some file system corruption <sturm>thanks civodul. I guess a `git gc` might remove that file? <civodul>you might need ‘guix gc --verify=contents’ <jaft>Is it possible to capture the output of ~guix upgrade~ in a Bash variable? <melito>I'm using Circe version 2.12 with GNU Emacs 29.2.50 (of 2024-03-11) <freakingpenguin>Hi Guix. I noticed that derivation-outupts of packages contains an extra "" entry. Anyone know why that is? It messes up eshell command substitution. <hapst3r>I've got a Scheme question: a thunk is a function which takes no arguments but computes something (and maybe memoizes the results). How is that different from a variable which computes something upon its invocation? <hapst3r>I might be confused, because in Common Lisp that definately is a thing, whereas in Scheme it seems like the might be the same. <jaft>hapst3r: how's the Common LISP variable computing something on calling (I'm assuming calling, here, is when being used; like, say, ~1 + variable + 3~ and not during variable definition/initialization)? <erikeah>I've a problem, etc/profile.d is not been sourced, a package in which I notice is nix. Why is this happening? <hapst3r>jaft: yeah, I believe you are correct and this is a difference. I thought that a variable would be recomputed on every call (and I believe this is the case), but in Scheme, defining a variable is no different from defining a function regarding the means of definition <spnjorfz>Hello, does anyone know if there is a modern gaming GPU that can be used with linux-libre? <eroesch>@spnjorfz, that would probably be a question for the #nonguix channel, I guess? <AwesomeAdam54321>eroesch: I don't think so, he asked about a GPU that works with linux-libre <eroesch>@AwesomeAdam54321 Oh I see. Yes, you're probably right. <jaft>hapst3r: are you sure Common LISP does that? I haven't really used any CLs, sticking largely to Scheme and Elisp, but recalculating variables every time they're used – as default behavior – would create very inefficient code as there's – effectively – no way to compute something once and just store that value somewhere. It'd be the first programming language I've ever encountered which does <jaft>that (but I could also possibly just be misunderstanding; 🙂. Not /terribly/ uncommon, for me). <hapst3r>jaft: yep, you're correct, somehow I thought that was the case because of the difference between DEFVAR and DEFPARAMETER, but my notes didn't corroborate that ;-) <jpoiret>apteryx: just merged, pushing and will build images today while i ork <civodul>i completely overlooked that when testing locally <cbaines>civodul, maybe, but not yet since the data service hasn't processed the revision <civodul>so in this case it’s just that the Data Service is too busy already, right? <cbaines>civodul, yeah, it's been struggling to keep up <cbaines>I thought I had got things processing a bit quicker, and I had, although I think that for revisions with lots of new derivations, the guix-daemon WAL was excessively growing <cbaines>also, the cleanup tasks weren't running <cbaines>I think I've fixed things up a bit, so hopefully it might start to catch up <cbaines>I've added prioritisation in for branches over patches though, which I think is helpful, but if there's lots of activity for branches, that will slow processing patches down <sneek>Welcome back drupol, you have 1 message! <sneek>drupol, old says: send me your mail in private ; I have feedback for you <drupol>I have a file `guix.scm` that builds a simple C program. I would like to lock dependencies in time. What's the best way to do that? <civodul>cbaines: uh, we start to see interesting problems at that scale :-) <janneke>drupol: for those cases i have a comment in my guix.scm, something like <janneke>;; To use the canonical commit that has everything prebuilt: <janneke>;; guix time-machine --commit=10f3dd0e9e06d71d1bc1615c6a60cc3aa1ad1ff4 -- shell <drupol>Oh interesting. Is it possible to embed this in the `guix.scm` file ? <janneke>you'd have to type that as a developer <fnat>Does 'guix deploy' saves the system configuration on the target machine? <fnat>Ah, yes, in the store. 'guix system describe' gives the full path. (On the target machine.) <sadie_>is there reason to use the home-zsh service over treating it like any other config file with home-dotfiles? <PotentialUser-78>Hi everybody. I'm having trouble getting a file from ci.guix.gnu.org. It's downloading super slow. Could by my connection, but thought I'd check. Are there any known issues with that site? <apteryx>no know issue, it depends on your ISP peering a lot, it seems <cbaines>and mirrors are easy to set up, hopefully we can make more progress on nar delivery soon <civodul>“bordeaux-us-east” sounds a bit like “Paris, Texas” <civodul>ACTION is barely semi-constructive today <cbaines>I'm sure we can have plenty of fun with domain names though <fnat>The issue appears when I guix-deploy an updated config.scm where I add an IPv6 static address. <fnat>The deploy seems to have succeeded but when I go and try to 'herd restart networking', that's when I see the error. (And I'm cut out from the connection if I do that via 'guix deploy ... --execute ...'. <civodul>fnat: error 17 is also known as EEXIST, meaning: that network route already exists <civodul>so it’s a bit of a bummer, but it means that ‘networking’ is trying to create something that already exists <fnat>Hm, ok, thanks civodul. I'm trying the workarounds suggested in the issue thread. <fnat>Hm, ok, the workarounds mentioned in the bug report don't seem to work for me. I'll explore this a bit further and then I guess follow-up on 64653@debbugs.gnu.org. <pfna>Does what guix does count as static linking? <ieure>pfna, What thing Guix does, specifically? <pfna>Reproducible building, package structuring on the disk, etc <pfna>or, more pointedly, the build process <ieure>Static linking, to me, has a pretty precise meaning, which doesn't seem to overlap with any of that stuff, so I'm not really sure what commonalities you're seeing. <reedm>Hi All. Is there a nice way to iterate over all packages in a module? For instance, if I wanted to get a list of uri's from every package in (gnu packages crates-io) <pfna>ieure: I was mostly stripping away what it isn't to understand what it is, so that's helpful. <ieure>pfna, Guix is a largish system which does multiple things. For the build system, I'd describe that as "repeatable builds" (you should be able to build the same software at different times and produce the same result) and also "isolated builds" (the build process doesn't depend on system state). <pfna>Mm. Very interesting. Does the isolated build concept allow someone to then statically link something, though? Sounds easier if that's the case. <ieure>pfna, You can statically link in any kind of build. <pfna>And is a statically linked binary not the same thing as a binary that you could run anywhere? <pfna>What's the difference? If something was statically linked, is it not able to run on anything of the same architecture? <ieure>It can run on any OS which understands the binary format *and* supports the system calls it needs. <bjc>these are orthogonal concerns <ieure>It limits "anywhere" is my point. <bjc>static linking merely means that when a binary is built it contains no references to external libraries <pfna>Fair enough. My main idea, currently, to cheat some software onto my guix installation without worrying about a few things, is to build it somewhere on one machine and then bring it over as a big blob. <bjc>guix normally doesn't statically link things, because it interferes with other things it likes to do, but you can still package up a tarball of something and run it on any linux distro <bjc>s/of something/of something guix built/ <pfna>Oh, do shared libraries have a similar situation to dlls, where the linker will look locally first? <bjc>dlls are shared libraries, but in unix land they have “.so” extensions, meaning “shared object” <pfna>I guess I'll have to bite the bullet and learn to use the package manager. <ieure>DLLs/SOs are the same idea, yeah. <ieure>Not sure whattwu mean about "look *first*." Either way, the code the program needs to run is in an external file; it'd be pointless to both bundle the lib in the binary *and* load it dynamically from an external file. <ieure>Library code can be in the binary you run (static linking) or in an external library which is loaded into the process (dynamic linking). <bjc>on most *nix systems, there's a configured priority for shared library locations that are used at runtime, and can be overridden with the “LD_LIBRARY_PATH” environment variable <bjc>guix uses this a lot <ieure>Dynamic linking saves disk space (one copy of the library instead of N per program that uses it) and lets you update the library without rebuilding (by replacing the .so file on disk). <ieure>Guix's way of doing things precludes some of that; it trades those optimizations for repatable builds. <pfna>Have you tested how much disk space you've 'lost' on your machine for this? <bjc>guix doesn't use shared libraries to save space at all <ieure>No. My impression is that Guix is a heavier distro than traditional Linuxen, disk-space-wise. <bjc>the main reason for shared libs with guix, as i understand it, is for security updates through the “graft” mechanism. otherwise they're pointless <ieure>bjc, Right; and you can't update a library dep without rebuilding the stuff it depends on. <ieure>But the normal flow -- you rebuild to update. <bjc>in fact, they have a distinct cost due to having them scattered everywhere under the store. there's a blog post about solving the symbol lookup storm <bjc>but if not for grafting, we'd be better off strictly static <bjc>well, i guess that's not entirely true. but it's close enough <civodul>hmm is it me or mail is reaching guix-patches slowly today? <henk_guix>I've asked before but never was able to successfully build a python/rust hybrid package called python-polars. I've found python-rpds-py as an example, but I get some error about a package that could not be built because the (cargo) manifest is not a package manifest (so apparently it's a workspace if I googled correctly) <jpoiret>ieure, pfna, bjc: wrt. disk space, if you just keep one generation at a time you don't really "lose" space. <jpoiret>so in a way it's only the "extra feature" of Guix of being able to have multiple generations on the same system that makes you use more disk space <jpoiret>and guix *does* save a lot of space with shared libs <bjc>ah, right. i keep thinking that it's common for dependencies to be pinned, but that doesn't happen all that often in guix <pfna>I remember prior to my understanding, when I then gained 150GB of disk space <podiki>oh nice, guix service has channels field 883e69cdfd226c8f40b6e3b76ce0740b59857de6 <podiki>so i would assume a reconfigure with adding a channel here, then guix pull, gets one using a new channel? <pfna>How does guix have it both ways? <pfna>To clarify, how does guix statically link, but put everything together in little bundles? <PotentialUser17>Wanted to ask about this again: does anyone know how to install jupyter lab in guix, or if it's even been packaged? I see that there is python-jupyterlab-server but that doesn't seem to provide the "jupyter lab" command. There's a lot of jupyter packages and it's not clear to me what each actually provides <jackhill>PotentialUser17: I think you're right that it may not yet be packaged for Guix. I see it's written in typescrypt which is a lot of work to package right now, so that probably explains it. I'm sure there's interest. <jpoiret>pfna: guix pack just distributes the .so files and uses a jail-like mechanism to make the programs believe the archive's contents are actually in /gnu <jpoiret>That way the exact same binaries can load the exact same libraries without actually installing anything <ulfvonbelow>is anyone else having trouble getting substitutes for guix pull? <ulfvonbelow>even when I use --commit with commits that have successful evaluations on ci.guix.gnu.org, nothing gets substituted <ulfvonbelow>this is on a fresh install from 1.4.0, so it should have substitutes enabled, right? <apteryx>are there long time Xfce users here? <elb>I've used it off and on on resource-constrained machines and VMs for years <elb>but I wouldn't call myself a "regular" user <ulfvonbelow>speaking of resource-constrained, it turns out that 'guix pull' takes spectacularly long on a system with only 1GB RAM (the rest being swap) <apteryx>elb: are the function buttons on a laptop like volume buttons or sleep supposed to work? <apteryx>they don't do anything with Guix System + Xfce <elb>uh ... in my experience that's not an answerable question on any Linux DE on any base system ;-) <elb>sometimes they do, sometimes they don't <apteryx>only the brightness buttons seem to have some effect <elb>brightness is possibly handled by acpi or something, not xfce <elb>(or maybe they're just plumbed correctly, and the others are not) <apteryx>there's some overlay that makes it look like it's handled by Xfce <elb>you might try running xev from a terminal window, mousing over the xev window, and pressing the various buttons <elb>see if they're even bound to the right X11 key events <elb>hmmmm yeah there should be an X session log, although I'm not entirely sure where you would find it on a default session; I normally use xsession, so they show up in ~/.xsession-errors <apteryx>oh, synopsis: XFCE volume keys daemon for the package xfce4-volumed-pulse <apteryx>err, from the xfce4-volumed-pulse package <ulfvonbelow>for example, cee74f3 has supposedly been built by ci.guix.gnu.org, but when I try running guix pull --commit=cee74f3, it starts building stuff after the long 'computing guix derivation' step <apteryx>I guess our xfce meta-package should propagate xfce4-volumed-pulse <apteryx>hm, tried to use goffice, but it provides no binary? <dariqq>hi guix: Just saw 883e69cdfd226c8f40b6e3b76ce0740b59857de6 . Would it make sense to also add the channels field to guix-extension? <apteryx>via a Unix socket (/var/guix/daemon-socket/socket) <mik3d>guixbui+ 594248 0.1 0.0 137932 10616 ? Ssl 22:23 0:00 \_ guile --no-auto-compile /gnu/store/8aq26yrh4yra2qc33i82wyil46p8b3mx-guix-package-cache-builder <mik3d>guixbui+ 594264 178 0.1 754020 503492 ? Rl 22:23 0:50 \_ /gnu/store/vqkjfl6ds3vdvig2x5pkvvzkc3wivrp0-guile-wrapper/bin/guile --no-auto-compile /gnu/store/ks7qzhazicpkyixjspv8qdxz6mhdy3an-profile/bin/guix repl -t machine <mik3d>it apears that this might be the build