IRC channel logs


back to list of logs

<luchadoritos>Hello Guix! Has anyone gotten Emacs Application Framework ( ) to run on Guix?
***rekado_ is now known as rekado
<EMax`0Mancer[m]>weird error trying to run a package installed from Nix on a Guix system: `/nix/store/.....-glibc-2.34-115/lib/ version `GLIBC_PRIVATE' not found (required by /gnu/store/....-glibc-2.33/lib/`
***Xenguy__ is now known as Xenguy
<piethesailor>Anyone here ever use the boxes vm?
<piethesailor>that comes with guix?
***user3456_ is now known as user3456
<littlebobeep>I am curious if anyone here uses Xen
<littlebobeep>I am curious why Xen is not supported on aarch64
<vagrantc>littlebobeep: most likely because nobody worked to implement it
<littlebobeep>vagrantc: ok
***Xenguy_ is now known as Xenguy
<piethesailor>yeah I am still having issues with boxes.. Is there a set up process required before using?
<piethesailor>anyone have a good resource on this?
<piethesailor>Also, is virtualbox downloadable through guix?
<piethesailor>Ah! gnome-boxes is a front end for qemu. Need that..
<vagrantc>seems like it ought to have a reference baked in for qemu if there's really no other way to use it
<piethesailor>Virtualization extensions are unavailable.. check BIOS settings to enable?
<piethesailor>next issue to solve lol
<vagrantc>ls -l /dev/kvm ?
<vagrantc>might need to add your user to a group to access that file
<piethesailor>hmmm.. I think your right. any good resource for doing that?
<xelxebar>piethesailor: Are you on a Guix System?
<piethesailor>yeah I am running guix as OS
<xelxebar>Cool. Then check out the supplementary-groups spec of your user definition.
<piethesailor> (supplementary-groups
<piethesailor> '("wheel" "netdev" "audio" "video"))
<piethesailor>I found this is system.scm, is that where I should be looking?
<piethesailor>this in*
<xelxebar>piethesailor: If system.scm is where your operating-system definition is, then yeah.
<piethesailor>Ah, yes. Is it as simple as adding "kvm" to that quoted list?
<piethesailor>or something along those lines?
<xelxebar>Yeah, the kvm group should already be specified by default, so just adding its name there should work. Does on my system, at least :)
<xelxebar>FWIW, supplementary-groups is documented in the Guix manual, too:
<luishgh>hi guix, can you define dynamic package inputs with the new-style notation or do you need to keep using the old-style in this cases?
<xelxebar>Sorry, gotta bounce. Good luck!
<piethesailor>Okay! Thanks xelxebar
<xelxebar>luishgh: (list pkg "output")?
<luishgh>for example: (inputs (list foo (if (bla?) bar)))
<luishgh>i'm trying to convert neovim's inputs to the new style, but the code that chooses between luajit and lua5.1 depending on luajit supporting the target-architecture seems to have stopped working
<luishgh>currently it is done this way: ("lua" ,(if (member (if (%current-target-system) (gnu-triplet->nix-system (%current-target-system)) (%current-system)) (package-supported-systems luajit)) luajit lua-5.1))
<luishgh>i assumed i just needed to put the part after the comma inside the list arguments and it would work, but now it tries to compile neovim with luajit on unsupported platforms
<piethesailor>I have made changes to my user configuration but I'm not seeing any changes with rebbot
<atka>piethesailor: did you run guix system reconfigure after you edited your config?
<piethesailor>No.. :facepalm:
<piethesailor>Is that command guix system reconfigure -k /path/to/system.scm?
<piethesailor>or rather without the -k flag
<atka>sudo guix system reconfigure /path/to/config.scm
<piethesailor>yea, okay thanks!
<piethesailor>This seems like it will be a lengthy process..
<atka>well depending what you have done since your last reconfigure it can
<atka>guix pull etc
<luishgh>oh, just managed to get it to work, never mind haha
<lilyp>with rust, rust is more a downside than up
<jgibbons[m]>On startup, Solfege shows an error to send upstream. Might be missing dependency = guix problem?
***daviid` is now known as daviid
<ZhuAisi[m]>How can I get rid of warning "pulled channel 'xxxxx' from a mirror of xxxxxx"
<ZhuAisi[m]>I move my personal channel to another server
<ZhuAisi[m]>And I edit the /etc/guix/channels.scm, now Guix warns that I'm using a mirror
<FlaminWalrus>`guix pull` is giving me a non-forward update warning on the official channel...I'm moving to ffb616b69dced25b840f2e5178062072d89623eb from 42679e3f81a0fa61e225b1f6aa0e80e39625372f, and the URL is the usual GNU Savannah guix.git file. I don't think I've done anything wacky in the week since my last pull. Should I lose the tinfoil hat and force it? Did someone manage to get an unsigned commit through?
<abrenon>hi guix
<the_tubular>There was a thread about this on the mailing list FlaminWalrus
<FlaminWalrus>the_tubular: and the thread references some IRC buzz. Now that they mention it, I do recall people speaking of guix pull woes about a week ago...I went ahead and did --allow-downgrades because the target commit matches master@savannah, and so can hardly be a downgrade attack.
<the_tubular>Sorry, I remember seeing the thread a few days ago, people weren't talking about IRC IIRC
<the_tubular>But yeah, I really wonder what happened ...
<NinjaTrappeur>Hey! I'm trying to wrap my head around a confusing guix behaviour. I just built a new guix system (1h ago). I modified my system config to add a new package. After running guix system reconfigure, I'm up to download ~50MB of unrelated data to the package I just added. I'm also up to build guix-1.3.0rc2. Is there a way for me to understand what triggered that? A channel bump? How could I figure
<NinjaTrappeur>that out?
<NinjaTrappeur>Also, is there a way to explicitely pin my local system to a specific channel revision to prevent this kind of channel upgrade?
<NinjaTrappeur>Answering my own first question: the part I was missing in my mental model were grafts. I was operating on a outdated guix channel, hence locally grafting a bit too much stuff :)
<abrenon>I have certificate errors downloading HTTPS stuff from python within a container
<abrenon>anything special package to include there ? (I tried nss-certs to no avail)
<arjan>abrenon: I remember for a similar case also having to set some environment variable to point to the certs
<abrenon>ahh, good
<abrenon>I hope I can find which one
<NinjaTrappeur>abrenon: if your python software is based on requests, SSL_CERT_FILE is the one you're looking for.
<NinjaTrappeur>Requests sadly does not use your system /etc/ssl/certs certstore by default :(
<abrenon>NinjaTrappeur: thank you !! I'll try that
<abrenon>doesn't seem to work, I've tried SSL_CERT_DIR too but : S
<NinjaTrappeur>abrenon: :( Can you curl the same URL you're trying to download from your python software from within the container?
<abrenon>hmmm I don't really know what URL it's trying to pull
<abrenon>it's just NLTK downloading its stopwords
<abrenon>it may be but I'm not even sure
<abrenon>I tried pre-downloading it and exporting NLTK_DATA but that didn't work either
<abrenon>NinjaTrappeur: glad you answered your first question !
<abrenon>for the second one, I think the answer might be "inferiors"
<abrenon> seems to say it allows you to pick packages from a specific revision
<abrenon>now I don't know if you can use inferiors for the rest of the system, but it may be a lead
<abrenon>ahhh, interesting, if it is indeed the URL I pasted above, I can't download it with curl either
<abrenon>ok, apparently I needed to both preserve the variable(s ?) from the environment and add nss-certs to the packages
<abrenon>not sure why adding it in the first place wasn't enough but heh
<NinjaTrappeur>abrenon: thanks!
<abrenon>thanks to you !
*abrenon has generated a docker with the appropriate python packages to send to a colleague because their python environment is utterly messy and nothing works as expected any longer
<civodul>"guix pack" to the rescue? :-)
<abrenon>but it would work only on one of the targeted architecture, right ?
<abrenon>I'm stupid, so would the docker, no ?
<abrenon>why did I ever think I could do this
<allana>On a related note, I have been using guix pack -f docker for a bit now. Still unsure how to activate the profile but I do use the "--symlink" feature to make things from the profile findable. Is this the way?
<qzdlns[m]>do we fire boot messages to a log? I saw a flash of a fsck sector warning and would like to check the message before jumping into a live CD -- I've ripgrepped /var/log and searched dmesg so far to no avail
<NinjaTrappeur>Is there a way to save the channel revision I used (provenance in guix terms if I'm not mistaken?) to build a guix machine closure without having to rebuild guix locally (kind of expensive CPU-wise)?
***Guest28 is now known as davidl
<ZhuAisi[m]>Did garbage collect its store? Is all history build result is still available?
<ZhuAisi[m]>Is all history build result still avaliable?
<jpoiret>NinjaTrappeur: you could transfer the guix pull profile along with its closure
<jpoiret>a guix pull profile is a profile like any other, you can manipulate it with the same tools
<zacts>hi has KDE been ported to guix?
<zacts>ah, thanks
<zacts>what's stopping that?
<zacts>have any components towards this goal been accomplished?
***bandali_ is now known as bandali
<NinjaTrappeur>jpoiret: ah, good idea! Thanks
<davidl>mbakke: hi! just fyi: I sent you a pull request on github for the ganeti-instance-guix package.
<sneek>Yey! yewscion is back
<yewscion>sneek: botsnack.
<ZhuAisi[m]>zacts: No body is interested in that. And packaging KDE is hard mode
<ZhuAisi[m]>tons of deps
<zacts>ZhuAisi[m]: ah ok
<jpoiret>in fact, DEs don't cooperate well with guix/nix
<zacts>I wonder if you could mix guix with apt or something. like apt within guix.
<zacts>like contain apt packages into guix somehow
<jpoiret>they have to be patched a lot, patches which thus often break
<mbakke>davidl: wow, impressive work! it looks like the PR got closed though, perhaps by accident?
<jpoiret>zacts you wouldn't really be able to use those packages as is
<zacts>ah yeah
<mbakke>davidl: I probably won't have time to look at it until next week
<zacts>could you use NixOS KDE packages tho?
<jpoiret>well, if it's packaged by Nix, it's definitely packageable for guix
<zacts>yeah, KDE is packaged by Nix
<jpoiret>nix packages are often a good source of inspiration
<davidl>mbakke: actually it's a late bug fix. I opened a new a few mins ago. Thanks!
<zacts>can you directly use Nix packages with Guix?
<jpoiret>guix has a lot less volunteers
<jpoiret>you can use nix on guix, but they won't mix at all
<jpoiret>just like you can use Guix/Nix on Debian/others
<zacts>I just want a running KDE environment, but guix for everything else
<zacts>like, couldn't I install Nix on-top of guixOS?
<zacts>just for KDE
<zacts>perhaps that could help with gradually porting KDE to guix too
<jpoiret>you could definitely, but it'll be hard to have a boot-directly-to-KDE experience i think
<abrenon>jpoiret: I thought the nix package had been removed at some point last year ?
<ZhuAisi[m]>KDE on Nix has lots of magic and secret
<abrenon>was it only the importer ?
<zacts>oh really?
<zacts>didn't realize that
<ZhuAisi[m]>I can't understand all of these configurations
<zacts>also, how might guix work with something like kubernetes?
<zacts>(just curious)
<zacts>has i3wm/sway been ported to guix?
<ZhuAisi[m]>🤔 Guix is similar with Kubernetes I think
*zacts looks
<ZhuAisi[m]>with `guix deploy` you can deploy Guix system to many machines
<zacts>oh nice
<ZhuAisi[m]>i3wm & sway is available
<zacts>I'd be fine with i3wm/sway.
<ZhuAisi[m]>also for GNOME XFce Cinnmaon LXDE LXqt
<abrenon>zacts: running i3 right now
<ZhuAisi[m]>Only KDE is not working now
<ZhuAisi[m]>I wish there's something like flatpak for KDE
<zacts>how about fcitx-mozc?
<ZhuAisi[m]>so I can run KDE on Guix and keep my hands clean 😂
<zacts>I see anthy but not mozc
<apteryx>abrenon: it was just the importer yes
<zacts>can you manage and cluster running guix packages across nodes
<ZhuAisi[m]> this project looks promising, but I haven't try it.
<zacts>and scale that
<zacts>like what would the equivalent to a docker container be for guix?
<zacts>and can you manage running guix containers like that across nodes?
<ZhuAisi[m]>For something like `bubblewrap` use `guix shell -C`
<zacts>or does guix just deal with installing and managing packages (not running containers, but just packages)
<zacts>is guix just a better apt, or is it more than that?
<ZhuAisi[m]>To run a Guix system inside container, try `guix system vm`
<jpoiret>zacts: sway works well
<ZhuAisi[m]>To package a OCI compatiable container image, use `guix pack`
<zacts>oh cool
<jpoiret>k8s is go, so is a nightmare to package
<jpoiret>i don't think we have it
<zacts>yeah, but can guix provide similar functionality to what k8s does?
<jpoiret>you can think of guix like a `package/system library`, which also happens to have a CLI interface
<jpoiret>it definitely could
<zacts>ah cool
<ZhuAisi[m]>Is k8s executable statically linked? If so, you can run it without any ELF hacks
<jpoiret>we have our own container implementation in Guix
<jpoiret>but it would be a huge undertaking
<zacts>I see
<jpoiret>k8s and orchestrators in general are complicated software
<zacts>how might guix containers differ from FreeBSD jails for example
<zacts>or docker
<allana>I have an ambition to package kubernetes, but I have not started and I am not sure if it's even possible (by me)
<ZhuAisi[m]>Guix container use Linux namespace tech,
<ZhuAisi[m]>So the difference is the difference between Linux namespace & FreeBSD jail?
<zacts>I see
<jpoiret>guix containers use roughly the same techniques as docker (ie. linux namespaces)
<jpoiret>i don't think guix runs on BSDs but i could be wrong
<allana>I would actually love to see a "guix deploy" option for declaring kubernetes clusters. Maybe I will find out how far I can get in the coming months
<zacts>perhaps with a Linux emulation layer it might be possible
<zacts>re: FreeBSD
<zacts>allana: cool
<ZhuAisi[m]>The main pain of Guix containers is missing something like network bridging and port forwarding
<jpoiret>namespaces are very linux-centric and a very deeply integrated feature
<jpoiret>i'm not sure you could simulate that
<jpoiret>ZhuAisi[m]: isn't that just a matter of making a proper iptables interface?
<ZhuAisi[m]>And create veth manually 🤔
<ZhuAisi[m]>Can I create veth in a declarative way?
<jpoiret>we have the static network interfaces that were recently reworked
<jpoiret>so maybe it's possible to use that
<ZhuAisi[m]>Thank you, I'll investigate into it.
<zacts>what are the main development goals for guix at the moment (for the next major releases)?
<zacts>what is most of the development effort focused on at the moment?
<jpoiret>the thing is, guix is very much rolling-release, even for its features
<jpoiret>point releases are very much just snapshots, but new features are introduced at basically any time
<ZhuAisi[m]>No security updates will be backported
<ZhuAisi[m]>So Guix is a rolling-release
<jpoiret>there isn't really a roadmap i'd say, even though there kind of is a wishlist
<jpoiret>there aren't that many contributors working on Guix internals, so adding new big features is pretty complicated
<attila_lendvai>in the new input format, is there a way to have named inputs? or is that deprecated and will be removed completely?
<mbakke>attila_lendvai: it will be removed completely, you should use search-input-file & co instead
<attila_lendvai>mbakke, thanks!
<civodul>so, comrades, we have a review problem!
<hibiki>what's up?
<civodul>i'm starting work on a "guix review" tool in the hope it'll help reviewers
<civodul>hibiki: an ever-increasing backlog of contributions
<hibiki>a pleasant problem to have :-)
<civodul>contributors turned away by the lack of responsiveness and all that
<hibiki>oh no
<civodul>well, review activity has also dropped lately
<civodul>so we need to do something
<jgibbons[m]>Calls to guix home reconfigure don't exit. I'm seeing right now if the problem is my home configuration or the guix home reconfigure script.
<EMax`0Mancer[m]>jgibbons[m]: seem to be having the same issue
<jgibbons[m]>'(E . Max `(0 ,Mancer)): Probably the latter then. i'm making sure the complexity of my configuration isn't the issue.
<jgibbons[m]>A config with a single item does exit
<EMax`0Mancer[m]>but it seems to have just started, as yesterday it was fine. (Unless the last changes I did also increased the complexity of my configuration to a similar point.)
<jgibbons[m]>3 packages won't break it.
<char[m]>Good morning guix! Is it possible to use vixie crontab files with guix mcron service?
<jgibbons[m]>char: Yes. Let me pull up the documentation
<char[m]>I read how to do it with mcron, but I couldn't see how to get it to work with mcron-service-type
<EMax`0Mancer[m]>jgibbons the last thing I changed was adding a "(options->transformation" .... -
<jgibbons[m]>char: I'm not sure then. The mcron-service-type might be too lispy.
<jgibbons[m]>The documentation says mcron-service-type expects g-exps corresponding to an mcron job specification.
<char[m]>Mcron says if run without arguments it will look for and run the crontab files, but running mcron-service-type without any jobs doesn't work.
<jgibbons[m]>Maybe if the gexp referenced a file. Like (local-file "/path/to/cron/file") or something like that it might work.
<char[m]>I'll try that, I still don't understand g expressions or how a file-like-object is a g expression
<jgibbons[m]>I know that gexp is supposed to be a monad, and nobody understands monads. So I would be surprised if anyone understood gexps.
<bjc>if i have a file-like-object (say, <computed-file>) how can i coerce the store from the repl to put that on disk so i can look at its contents?
<jgibbons[m]>Somehow gexps usually turn into strings referencing a location in a file system, so I think a file-like object can stand in for a gexp.
<bjc>i don't need it outside of /gnu/store, but i don't even know how to get that far
<bjc>been banging my head on this for a couple days and i just can't find my way around to it
<jgibbons[m]>bjc: If I am correct that file-like objects are gexps, then you should be able to use the store monad with file-like objects. Worth checking either way.
<bjc>yeah, i've read that a bunch of times and i still have no idea
<bjc>fwiw, 'gexp?' on a <computed-file> => #f
<jgibbons[m]>"The local-file, plain-file, computed-file, program-file, and scheme-file procedures below return file-like objects. That is, when unquoted in a G-expression, these objects lead to a file in the store. Consider this G-expression:"
<bjc>so i can just unquote it? i think i was thrown off by the 'system*' call in the beginning of the expression
<jgibbons[m]>You could try something like #~(begin #$(local-file "/path/to/file"))
<bjc>i'm going to try and simplify my working case to express my issues better
<bjc>i still think i'm missing a step
<jgibbons[m]>#~(local-file "/path/to/file") returns a gexp. (gexp->derivation "stuff" #~(local-file /path/to/file")) returns a derivation.
<jgibbons[m]>Send that derivation to a store.
<civodul>jgibbons[m]: i'm seeing the same problem with "guix home reconfigure"; i think it has to do with the shepherd ugprade
<civodul>it hangs while running "herd load root ..."
<jgibbons[m]>So if I remove my services, it might not hang?
<jgibbons[m]>shepherd services
<civodul>you can run "herd stop root" before "guix home reconfigure"
<civodul>but then shepherd isn't running anymore
<civodul>and reconfigure won't restart it, it seems
<jgibbons[m]>Have you filed a bug report?
<civodul>jgibbons[m]: i see there's one here:
<civodul>i've just replied
<bjc>there's .. oh
<bjc>was just looking for that ;)
<jgibbons[m]>\me reboots and logs in to start home shepherd
*jgibbons[m] reboots and logs in to start home shepherd
<civodul>jgibbons[m]: i posted a patch there; would be great if you could test and report back
<GNUverkty[m]>when will gnunet-gtk work?
<bjc>ok, so if i create the following derivation:
<bjc>(define test-drv (gexp->derivation "foo"
<bjc> #~(begin #$(plain-file "foo.txt" "the contents of foo")
<bjc> (display "ok"))))
<bjc>when i call (let ((store (open-connection))) (build-derivations store (list (run-with-store store test-drv)))) => #t
<bjc>that's not useful for me. i assume i'm missing a step
<bjc>what i'd like is to run the derivation and get the "foo.txt" output location in the store so i can manually inspect it
<bjc>kind of like what this does at the repl: ,enter-store-monad RET (text-file "foo.txt" "contents")
<bjc>or am i way off base here and need to approach this from a different angle?
<jgibbons[m]>bjc: Try it with gexp #~(display #$(plain-file "foo.txt" "the contents of foo"))
<bjc>=> #t
<bjc>there's no output at all from display, presumably because that runs in the guix daemon, not in my repl
<bjc>i only added it there as a hail mary
<bjc>should i take this to the mailing list? i'm so lost
<jgibbons[m]>It wouldn't hurt.
<jpoiret>bjc: personally i'd say you would have to use the monadic procedure (lower-object ...) from (guix gexp) tice
<jpoiret>twice *
<jpoiret>it will work, but there might be something better
<jpoiret>maybe lower+expand-object instead, have not used it
<bjc>jpoiret: i'm not entirely sure what lower-object does, but i'd guessed it was too low level for what, i'm presuming, is a common thing to do
<bjc>and why twice?
<jpoiret>oh, right, you're building a derivation, one lower-object will be enough
<bjc>where does it go? i've tried wrapping 'test-drv' -- (run-with-store (open-connection) (lower-object test-drv)) -- and it throws an error
<bjc>likewise, wrapping (run-with-store) in it also throws an error
<jpoiret>wdym it throws an error?
<jgibbons[m]>(let* ((store (open-connection))
<jgibbons[m]> (drv (run-with-store store test-drv)))
<jgibbons[m]> (format #t "~a~%" (derivation-outputs drv))))
<bjc>there's no 'lower-object' call in there
<jpoiret>what exactly is the error?
<bjc>(run-with-store (open-connection) (lower-object test-drv)) => In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<procedure 7f81189803c0 at guix/gexp.scm:1180:2 (state)>
<netamuffin[m]>Hello! Are there packages or other ways to use rust nightly on guix?
<jpoiret>netamuffin[m]: unfortunately not afaik
<bjc>you can't use rustup?
<netamuffin[m]>bjc: rustup doesn't have any binaries that were patched to work on guix, right?
<jpoiret>guix functions differently enough that bare rustup wouldn't work
<netamuffin[m]>* guix, right? (also no package for rustup)
*jgibbons[m] looks for rust nightly on dockerhub
<jgibbons[m]>If you need rust nigthly, you can make it with docker from rustlang/rust:nightly
<netamuffin[m]>jgibbons[m]: eww docker
<jgibbons[m]>How to build rust nightly? Special branch on a git repo?
<netamuffin[m]>Bootstrapping rust seems plausible
<netamuffin[m]>* seems plausible - lets see
<jpoiret>bjc: right, it's my bad here
<jpoiret>you need `(run-with-store (open-connection) (with-monad %store-monad (>>= test-drv lower-object)))`
<jpoiret>but there's definitely better i think
<bjc>i'll try that though
<jpoiret>actually scratch that
<bjc>i will also scratch that ;)
<jpoiret>it'll just give you the derivation, because silly me forgot that lower-object doesn't build anything (:
<bjc>right. i'm pretty sure i've *got* the derivation, but i don't know how to run it, and 'run-with-store' isn't doing what i expected
<jpoiret>yeah, run-with-store will just execute an mval with a store connection
<jgibbons[m]>Location should be in derivation-outputs
<bjc>and the derivation isn't a monadic value?
<jpoiret>the mval you're executing is given by (gexp->derivation ...) so basically you'll just get the derivation path
<bjc>right, that's what i'm getting
<jpoiret>no! you're executing a monadic derivation, ie something that needs the store to give you the derivation path
<jpoiret>a derivation itself isn't monadic at all
<bjc>that makes sense, since i never gave it the store monad
<bjc>so i have to turn it into an mval, then, to execute it?
<jpoiret>no, you should use build/build-things/mapm/accumulate-builds or similar
<jpoiret>basically yeah, it turns a derivation into monadic value (but that value isn't the output path iiuc, which is annoying)
<bjc>unfortunately (build-derivations store (run-with-store store test-drv)) doesn't give me anything i can inspect
<jpoiret>well, yeah, as jgibbons was saying, you should use derivation-output-path to get that
<civodul>bjc: these are rather low-level APIs; it's okay to use them, but be sure you really need it
<jgibbons[m]>But the output paths are empty
<civodul>in most cases, you can use 'computed-file' & co., and pass that to "guix build" or similar
<jpoiret>yeah, because the derivation doesn't build anything iiuc
<jpoiret>you're not trying to use #$output inside the gexp, so it doesn't have an output i think
<bjc>civodul: i don't know the appropriate level to be working at. i *do* have a computed-file that i'm trying to use, but i also need to be doing this in scheme
<jpoiret>what are you trying to achieve at the higher-level?
<bjc>i intend to create a package that can write out the file, but, while i'm working on it, i want to verify its contents
<jpoiret>so you're writing a phase gexp, and you want to inspect a file? can't you do that directly inside the gexp?
<bjc>i don't want to have to call 'guix build' all the time. i'd rather be doing as much as i can from geiser and its repl
<bjc>i want to verify the actual file contents
<bjc>i'm pulling the computed file from the grub bootloader, and its not the kind of thing i'd want to install if it has an error in it, for instance
<jpoiret>looking at the `guix build` source, it really does (build derivations ...) followed by (for-each show-derivation-outputs drv)
<bjc>plus, this seems like fairly basic functionality to me? maybe i'm odd, but going from file-like-object to actual file in scheme seems like the kind of thing you'd get in a beginner hacker tutorial
<jpoiret>often, you just `guix build -f` file-likes
<jpoiret>or -e
<bjc>can i do that from the repl?
<jpoiret>nope, i don't think so
<jpoiret>from the repl you really have to `build-derivations` followed by `derivation-output-path`
<bjc>build-derivations just returns #t, though. what do i call derivation-output-path on?
<jpoiret>let me check though if there isn't something easier
<jpoiret>bjc: you call it on the original derivation
<jpoiret>derivations always already know their output path, so as long as they build you know where the output is
<jpoiret>if you just print out the derivation in the shell, it will display it nicely along with its outputs
<ZhuAisi[m]>it will be handy if we can build something in REPL directly
<ZhuAisi[m]>Maybe add some repl command like ,build GEXP-LIKE-OBJECT
<jpoiret>you're looking for file-likes :p
<bjc>jpoiret: so, i'd call 'derivation-output-path' on: (gexp->derivation "foo" #~(begin #$(plain-file "foo.txt" "foo contents")))
<jpoiret>no, you'd have to run it first to get the actual derivation
<jpoiret>but you could also write most of it using monadic style
<bjc>i'm not following
<bjc>you mean i need to run build-derivations, *then* run derivation-output-path on something?
<jpoiret>something like (mlet* %store-monad ((drv (gexp->derivation gexp)) (output (derivation-output-path drv))) (begin (build-derivations (list drv)) (format #t "~a~%" output)))
<jgibbons[m]>gexp->derivation seems like a misnomer. It returns a procedure, not a derivation object.
<jpoiret>it returns a monadic value to be exact
<jpoiret>the fact that the internals of monadic values are procedures shouldn't matter
<jpoiret>ah, and it should likely be (output <- (derivation-output-path drv)) instead
<bjc>Wrong number of arguments to #<procedure gexp->derivation
<bjc>oh wait
<jpoiret>let me fire up something to actually test out what i'm saying, cause it's all vague
<bjc>ok, so that returns a procedure, which i guess i have to (return) to get its value?
<PotentialUser-97>Hi can anyone advise how to set dconf settings fro Gnome via guix or guix home?
<bjc>actually, that procedure should probably go through run-with-store, right?
<bjc>but trying that and i get: Wrong type argument: #<derivation /gnu/store/dr813a1m81rzmprnig1kpqah3f3gd1hd-foo.drv => 7f8114d70dc0>
<netamuffin[m]><netamuffin[m]> "Bootstrapping rust seems..." <- Also bootstrapping rust failed, because of an unknown issue i cant resolve.
<netamuffin[m]>Also while searching i came across this piece of text (from
<netamuffin[m]>> Thiago Jung Bauermann - I learned about Guix when I was looking for alternative, safe ways of installing an up-to-date Rust toolchain on my machine...
<netamuffin[m]>Seems a little ironic to me now.
<netamuffin[m]> * Also while searching i came across this piece of text (from
<netamuffin[m]>> Thiago Jung Bauermann - I learned about Guix when I was looking for alternative, safe ways of installing an up-to-date Rust toolchain on my machine...
<netamuffin[m]>Seems a little ironic to me now.
<bjc>it's not wrong, depending on what's meant by "safe"
<bjc>rustup, while it works, is a mess
<civodul>netamuffin[m]: not sure if that's what you're looking for, but Rust is bootstrapped (i.e., entirely built from source) on Guix:
<civodul>(and on Guix only IIRC)
<netamuffin[m]>yeah. still somehow funny to me.
<drakonis>i'm getting the itch to get guix back on my box again
<netamuffin[m]>civodul: the python script fails executing the prebuilt binaries for bootstrapping
<civodul>netamuffin[m]: i'm missing context; which python script?
<civodul>"guix weather rust" suggests binaries are available
<netamuffin[m]>The docs for building rust say that building is done with a provided python script `` instead of cargo.
<civodul>which docs?
<netamuffin[m]>civodul: They are the latest stable though. I need nightly
<jpoiret>you can build the newer rustcs using the stable ones
<civodul>ah well, that's not the right channel for complaints then :-)
<bjc>you may be best off just running rust in a container
<civodul>netamuffin[m]: for Guix, i'd suggest something like "guix build rust --with-source=http://.../rust-nightly.tgz"
<civodul>there's no guarantee of course, because you'd be building an arbitrary tarball from upstream
<netamuffin[m]>jpoiret: Thats would be cool, but the build script is untransparent for me and uses downloaded binaries that dont work on guix
<netamuffin[m]>civodul: Nice. Didn't know that existed, because i am new to guix. I will try it
<civodul>netamuffin[m]: yw; you can take a look at
<jpoiret>your best bet is writing a package for the version you want, with inspiration from the stable ones :)
<bjc>how would that work for a nightly package that updates every day?
<netamuffin[m]>I dont need them every day. I just need a relatively new version, which would be nightly in my case.
<jpoiret>why am i getting unbound symbol: 'ungexp' :(
<jgibbons[m]>bjc: Still working on verifying a file in the REPL?
<jgibbons[m]>(define test-drv (gexp->derivation "foo" #~(copy-file #$(plain-file "foo.txt" "the contents of foo") #$output))) (let* ((store (open-connection)) (drv (run-with-store store test-drv))) (build-derivations store (list drv)) (format #t "~a~%" (derivation-outputs drv)))
<bjc>yes i am
<bjc>lemme try that
<jgibbons[m]>That blob should get you started.
<civodul>bjc: --with-source accepts a URL, so it'd download that first
<char[m]>jgibbons: using local-file or just the file name as a string didn't work
<netamuffin[m]><netamuffin[m]> "Nice. Didn't know that existed..." <- Sadly didn't work. Would have been too nice
<bjc>jgibbons[m]: you are a hero. thank you
<jgibbons[m]>char: I've been working on correcting that. Try a gexp like #~(copy-file #$(local-file "/path/to/file") #$output)
<bjc>copy-file makes sense, and was the step i was missing
<jgibbons[m]>i don't know if there's a simpler way to get the gexp #~(copy-file #$file-like-object #$output)
<bjc>if i didn't want it to go to the output, maybe it'd be a problem, but i can't see a reason to want that right now
<jgibbons[m]>Also, if you are using local-file, unless you do something to make it unique based on the file's hash, you will need to garbage collect every time the local file changes.
<jgibbons[m]>At least, I think that's the case.
<jpoiret>bjc: here's my version
<sneek>Yey! yewscion is back :)
<jpoiret>i tried using monadic notation to make it cleaner :p
<yewscion>sneek: botsnack.
<jpoiret>also, don't use gexp as your gexp variable name, you'll run into nasty issues :(
<bjc>jpoiret: thanks, that was my next step
<bjc>(using monads)
<char[m]>jgibbons: what is output supposed to be?
<jgibbons[m]>output refers to the out output of the gexp and a location in the store.
<jgibbons[m]>So the gexp #~(copy-file #$file-like-object #$output) copies the file-like-object to its output and can be used to reference a location in the store like with a package.
<jgibbons[m]>I'm not familiar enough with mcron-service-type to know what it does with the gexp you give it in its configuration object though.
<littlebobeep>So there are 6 revisions of the ARMv8 ISA and now one ARMv9 version.... what versions of all of these aarch64 levels does Guix target?
<efraim>littlebobeep: v8a, but we do also have the --tune flag, which should help with later revisions
<char[m]>Arguments to mcron can be crontab files. Instead of putting the file name though, mcron-service-type keeps putting a file who's contents is a path to the crontab.
<littlebobeep>efraim: Okay would I have to edit the scheme package definitions to optimize for the correct ISA?
<efraim>littlebobeep: I'm not sure how to do it as part of a manifest, but it should be possible to just do `guix install foo --tune`
<efraim>oh, autotuning isn't setup yet for aarch64, I should've checked (guix cpu) first
<efraim>well they are listed as armv8-a through armv8.6-a, so it should be `guix install foo --tune=armv8.2-a` or the like
<efraim>littlebobeep: what machine do you have? I didn't have any that weren't armv8-a so I couldn't do anything with the autodetection yet
***chexum_ is now known as chexum
<leinad>Hello Guix! I just want to bring your attention to a fix for the failing cava build:
<char[m]>I found a read-vixie-file function in mcron source. It returns a list of jobs, but those aren't gexps, so I doubt it will ever work. I'm not sure sure how to load mcron source into my /etc/config.scm in the first place.
<sneek>yewscion: wb :)
<yewscion>sneek: botsnack.
<roptat>hi guix!
<leinad>char[m]: IIUC the mcron service only allows job descriptions in Scheme format. Reading the source, specifically the definition of the procedure job-files in gnu/services/mcron.scm:59:9, it appears to me that the gexps from the jobs field of the mcron-service-configuration is simply ungexp'ed and then quoted again and written to a Scheme file and passed to mcron.
<char[m]>Thanks leinad , I guess I will just conform then.
<leinad>Hopefully, you're going to like the Scheme forms eventually
<civodul>howdy roptat!
<roptat>hi ludo
<civodul>jpoiret: hey, any ideas about the swap/zram comment?
<bost>Hi. Does anybody know how to get the 'gsettings' installed?
<atka>civodul: zram-device-configuration has the priority field which can/should be defined when creating zram and/or multiple swaps, I think zram defualting to -1 or -2 is the default when starting zram with zramctl on other distros. Fedora uses zram instead of swap by default and defaults to 100.
<jonsger[m]>bost: guix shell/install glib:bin will do the trick :)
<bost>jonsger[m]: Thanks. Can tell me please how can I find out such things by myself?
<civodul>atka: ok, thanks for explaining; actually my question to jpoiret was more like: could you gimme a patch to apply? :-)
<civodul>i'm not too familiar with this
<civodul>bost: hi! it's usually installed with GNOME/GTK things
<atka>civodul: just tested on a fedora distro, creating zram, running mkswap, and running swapon with no priority argument defaults to -2, not a guix issue imo
<civodul>bost: you're getting warnings from a GTK app?
<jonsger[m]>find /gnu/store/ -name gsettings | grep "bin/gsettings" :P
<bost>jonsger[m]: will that find command work if I haven't installed 'glib' yet?
<bost>jonsger[m] civodul I mean I'd like to know how to find out from the guix source code that gsettings comes from glib:bin?
<jonsger[m]>no, it wont. There is no such a command in guix yet...
<bost>jonsger[m]: so in general I need to install as many packages as possible and then just run 'find ... | grep ...' and hope for the best? Hmm.
<jonsger[m]>or ask in IRC :)
<bost>jonsger[m]: uhmkey :)
<roptat> ls /gnu/store/*/bin/gsettings is faster than find ;)
<bjc>does guix even know what files are installed in a given package until it's built?
<bjc>feels like this is a job for the data service
<jpoiret>civodul: i'm not familiar with zram, but for swap the priority is pretty well explained in
<civodul>jpoiret: could you reply to the bug tracker?
<civodul>actually i was just scanning it for open bugs :-)
<jpoiret>i'll do that tomorrow!
<civodul>sure, no rush
<jpoiret>i'll have to read up a bit on zram first, but for sure :)
<civodul>heh :-)
<civodul>bjc: yup, or a custom database, as discussed at
<jonsger[m]>roptat: indeed, over 2x :)