<vagrantc>heh. finally updated a system with the shiny new progress bars. nice. :)
<bjc>and while you can call these procedures, i believe they return procedures themselves, which can only be used by the store monad to actually create the derivation
<mitchell>That's the part that trips me up I suppose. Monads are tough to wrap my head around
<bjc>you can basically ignore it as a concept, and just remember that this stuff has to be run in a store context
<mitchell>Well the documentation says that every procedure run in the store repl needs to return a monadic value
<mitchell>which i do not understand practically what that means
<bjc>guix only has the store monad (there's also state, but i don't think that's used), so all monadic values have to be run through the store. iirc the docs are pretty good at saying what returns a monadic value
<mitchell>So store items are monadic because they rely on the contents of the store. When I want guix to evaluate something and place it in the store it needs to be a monad because it modifies state?
<bjc>but it's worth remembering that the store is there to sequence events as you compose them, but nothing actually happens until you run it, with either ‘build-derivations’ or ‘built-derivations’
<bjc>i have some sample code from when i was trying to figure out an issue with geiser's repl output, which uses the store monad here: http://ix.io/4pka
<mitchell>I see. More like a list of lambdas that either all run and succeed or all fail
<bjc>ignore the output-port stuff. the mlet/mbegin should still work, though
<mitchell>you pass it around until everyone added what they want and then run it as a single action
<bjc>it's not necessarily transactional just because it's a monad, since a monad can break in the middle. i think guix adds some extra logic to the monad fail state to ensure transactionality though, yes
<bjc>the monad is there for easy composition of actions, though. so that part is correct
<mitchell>I thought the magic of functional programming (with monads) was that there was no observable state
<bjc>so guix can have machinery for a derivation building, which keeps track of what's been built, so that if it fails at some point, things can be rolled back, even if the individual derivations are only capable of signalling whether or not the've succeeded
<mitchell>lechner: The M*rosoft one? Only while googling for the GNU one
<bjc>although, tbh, i think guix just leaves all the garbage around, and is transactional just by way of not updating the profile and its generation symlink
<lechner>mitchell / i know! i just read up on it but Zephyr seems to more event-driven and better for low-power applications. Plus, it's supported by a larger number of vendors rather than owned by one
<lechner>is there a guide somewhere how i may try to build an image for my router, preferably using Guix? i have u-boot already and would prefer to keep it
<apteryx>e.g, datefudge "2022-05-01 00:00" make test TESTS=test_ssl_new VERBOSE=1 still fails with # 140520156960576:error:14094415:SSL routines:ssl3_read_bytes:sslv3 alert certificate expired:ssl/record/rec_layer_s3.c:1543:SSL alert number 45
<apteryx>well, replace that date by something like 2021-06-24 and it still fails
<mirai>lechner: I've yet to write a series of long-reads (i.e. drafts) to guix-devel concerning about services, file-systems, etc.
<haugh>Happy install to a new system, hangs on boot. Any pointers? Any required info?
<oriansj>haugh: hangs where and did you do encrypted volume and what is your system configuration?
<haugh>oriansj, did the bridge send my photo? the screenshot is the hung screen; can't switch tty, can't do anything but force shutdown with power button. yes LUKS, absolutely minimal system configuration. Have tried a few different configs, same result. No DE, no xorg, no wireless, etc.
<oriansj>ok, you are at a luks prompt. just type in your luks password and hit enter
<winter>maybe it's worth writing documentation for, hm. will need to look into it some more. seems like it's conventional to be adapted by all build systems, but notably can be forgotten (see 9e4d8c75183c226d0cba2de3b40e6a9e603ae43b)
<winter>note to self: actually do the git send-email dance next time i need to submit a cover letter, ugh. thought it would handle it with the in-reply-to header but guess i should have actually thought about it. sorry to whoever triages 61833 and 61834 :(
<lechner>winter / #61833 is an unrelated 'guix style' question. it's been asked many times before (including by me). the answer is to mark the region in Emacs instead and hit TAB. may i please close that bug?
<lilyp>I will treat it as a cover letter, because that's what winter said
<winter>It was intended to be a cover letter, yes.
<lechner>you don't think it's inconsequential to the diff?
<zacchae[m]>Trying to make a system service to spawn a login tmux, but inside the tmux, guix home fails to start because /run/users/1000 doesn't exist
<winter>ah just saw your response, thanks lilyp -- that's unfortunate. maybe a manual revision is in order, to at least dissuade its use for formatting (as opposed to rewriting input styles or phase modifications)
<zacchae[m]>Any idea how to force the creation of /run/users/1000? All the things that come up in search are systemd specific
<lilyp>there are no formal requirements w.r.t. what can go in a cover letter
<lilyp>zacchae[m]: check if it exists and create it in an activation/bash_profile hook?
<lilyp>it needs to be early enough for guix home to work
<apoorv569[m]>My build of DWM works fine I have it installed on another machine which does not run Guix.
<rdrg109_>[Q] My system have 92 generations, I have rolled back to the 74th generation. I want to delete the 75, 76, ..., 91, 92 generations. I have searched on the Internet, but only find information on deleting previous generations.
<rdrg109_>^ Solved! => $ guix package --delete-generations=75,76,77,78,79,80,81,82,83,84,85,86,87,88,89,90,91,92 <= Now I have another question. Is it possible to simply that command in order to avoid having to write a sequence of numbers (a suitable task for computers)?
<unwox>rdrg109_: "--delete-generations=75.." should work
<mfg[m]>when guix searching for rust you can also see the outputs. rust:rustfmt is one output of the rust package, but only up to a specific version afaik this is the one you are supposed to use in Guix
<mfg[m]>So not the newest rust, but the newest that has the rustfmt output. But I don't use rust myself.
<bumble[m]>hello unmatched-paren and unwox humble thank you. your config files have been incredibly useful for me to reference
<apoorv569[m]>mfg: I see. So I have to use which latest version has output for rust:rustfmt.
<mfg[m]>apoorv569: yeah, I don't know which version that is, I'd have to look it up.
<apoorv569[m]>Yea thats what I used to use. But there is no rustup package available.
<michaelll>apoorv569[m]: Run `curl -L sh.rustup.rs | bash` to install `rustup`
<zacchae[m]>lilyp: solution was a shepherd service with make-forkexec-constructor: tmux new-session -d "su [user] -l"
<michaelll>it is not installed by package manager, you can find more useful information on rustup.rs
<zacchae[m]>^ and for anyone else that wants a headless machine to launch guix home on startup
<daviwil>hey Guix! I just pulled latest Guix and for some reason `specification->package` can no longer seem to resolve "glib:bin" to the "bin" output of the "glib" package, I receive this error: "error: glib:bin: unknown package"
<daviwil>When I run `(specification->package "glib:bin")` in the guix repl, the error causes the REPL to exit immediately
<michaelll>If those advices from mfg[m] do not fit your need(it is almostly comprehensive), your best next try would be: use QEMU to do a full OS virtualization, those which are more friendly for Rust components installation, like Debian or Fedora. That way, you can use Guix as usual and writing Rust on it :)
<mfg[m]>Interesting rust also needs gcc-toolchain, because it's apparently using cc as the linker ...
<mfg[m]>maybe the project i'm trying to build is strange shrug
<mfg[m]>you could of course just write a long shell alias for your projects and use that; with the correct command it may not make difference in the end
<lain_>I believe the difference is that the guix.scm file is intended to be used to create a container in which *only* the programs and files described can be accessed, which makes it much easier for developers to define and keep track of all inputs used to compile their program
<mfg[m]>but if someone wants to contribute it's way faster to type guix shell -C -D -f guix.scm :D
<mfg[m]>lain_ you can certainly drop the -C then you don't have a container anymore, but a regular subshell. If you don't specify --pure this subshell will even inherit the env
<lain_>mfg maybe it's if you were using 2 different versions of the same package for different projects and wanted to keep them explicitly separate too
<mfg[m]>What i didn't know but read in the blog post is that you can even drop the -f guix.scm as guix shell will use a file with that name per default (if the directory is allowed in $HOME/.config/guix/shell-authorized-directories -- you don't want to eval arbitrary code)
<sneek>civodul, flatwhatson says: The libgc package uses the --disable-munmap configure flag as a workaround for this bug. That should be removed so libgc will actually release some memory. Testing locally, a libgc-8.2.2 build without --disable-munmap does pass test-out-of-memory, horay! Here's my hacked-up guile/guix.scm to reproduce that: https://paste.debian.net/1272261/
<nckx>daviwil: I don't think that has ever been expected to work (there's a ...+output variant for this; I won't bring up whether it should be the default). The REPL dying is, I think, new, though. Could you file a bug? Else I'll, but I might forget.
<nckx>civodul: I'm half-way through Josselin's video. Thanks for the recommendation.
<civodul>nckx: yw! i really enjoyed it, i think it has everything
<civodul>plus, i'm not following best practices :-/
<cbaines>civodul, I've pushed what's hopefully a fix now
<cbaines>at least this particular problem will go away when more/all packages use the new style
<cbaines>I wonder if it would be helpful to try to raise these issues earlier though, as currently you can compute the derivation fine, but the builder is never going to work
<cbaines>maybe it would be worth trying to spot that the builder is broken at the time the derivation is computed
<daviwil>nckx: Thanks! `specification->package+output` fixes the issue for me, I was using `specification->package` incorrectly in my Guix Home config, a recent commit must have fixed the "bug" that enabled me to get away with it for over a year :) I'll file a bug later when I have a chance
<GuixAdmirer96>civodul: I recently found out about Goblins and spent some time reading and watching videos about it :) I love it
<florhizome[m]>can we upgrade to libgudev-237 on core-updates? It will be needed for iio-sensor proxy
<apteryx>winter: I was trying to run the openssl test suite via datefudge or libfaketime, so that its certs would never expire on us
<apteryx>it doesn't seems easy to convince openssl to be tricked
<rdrg109_>[Q] What's the fastest and simplest package definition that you can think of? I'm asking this because I'm a newbie Guix user and I want to experiment with the => $ guix --package <= command and how it works in generation so I want my system to create generaations on the fly
<civodul>apteryx: great that you persevered on #58650; i wonder why it doesn't work as expected
<bjc>rdrg109_: ‘guix build -f’ may be what you're looking for
<apoorv569[m]>I have this lightdm-service-type defined, it installs and configures fine, but the session list on top right shows empty even though I have multiple window managers installed. Am I doing something wrong?
<winter>Upstream seems to have moved to give very large expiry dates on their test certs (100 years), so perhaps we can simply remove this test and hope the problem doesn't come back to haunt us... <-- Wouldn't removing the tests neutralize the issue, or am I misunderstanding what the test you're mentioning does? (Assuming the cert expiry is +100 years, it
<sepi>Is there a facility that would create MD raids, luks containers and filesystems from operating-system definitions? Or is this left out intentionally? I'm wondering how I would replicate my current system which uses all these mechanisms
<mirai>sepi: pretty sure no tools automatically do this from bare disks
<lechner>sepi / with all due respect, i thin that would be a big, and potientially dangerous, step
<apteryx>winter: on the master branch for example, openssl 1.1.1l is grafted with 1.1.1t, but to get the grafted version, you still need to build 1.1.1l, which fails to build. So you can't build Guix from source anymore (you need a substitute) on master.
<sepi>providing a an operating-system definition to the installer could be a way to go. In that case the installer would somehow try to initialize the disks and filesystems based on the config provided
<apteryx>on core-updates the problematic test is already skipped
<mirai>sepi: at that point you're no longer using the installer, you're using the cli
<lechner>Hi, after a pull, i can't deploy anymore Throw to key `guile-ssh-error' with args `("write_to_channel_port" "Parent session is not connected" #<unknown channel (freed) 7f1e5e6e6ce0> #f)'.
<sepi>mirai: but the installer does things like formatting and fs creation while the cli doesnt
<sepi>I imagine the installer being pre-loaded with the definition provided. This would essentially make you say yes everywhere to replicate a system.
<winter><apteryx> winter: on the master branch for example, openssl 1.1.1l is grafted with 1.1.1t, but to get the grafted version, you still need to build 1.1.1l, which fails to build. So you can't build Guix from source anymore (you need a substitute) on master. <-- ouch, that's a nasty side-effect. so you haven't been able to build Guix from source since
<sepi>mirai: I guess it's two different questions. One is about UI, the other about implementation. But anyways, good to know that I'll have to do this part myself and in case I want this functionality, I'll have to get my hands dirty :)
<mirai>lechner: Non-volatile infinite capacity disks are yet to be invented
<civodul>winter: between "infrequently" and "seldom"
<winter>that's a long time to not be able to build Guix from source, ow
<winter>(not that i'd be doing that any time soon, but still unfortunate)
<lechner>we are working on speeding that up, but you are right
<attila_lendvai>civodul, could it be that guile-fibers is not in the path when shepherd service start GEXP's are compiled? if yes, what's a shepherd user to do?
<attila_lendvai>civodul, in general, i assume i should allow the dependencies to enter the module closure using my custom filter function, e.g. for guile-json... but i guess for fibers it should be the same version that shepherd was compiled with, no the one in my compile-time guile module path, right?
<attila_lendvai>civodul, if i add (with-extensions (list (lookup-package-input shepherd "guile-fibers")) ...) around my service GEXP's, then i can make it compile with `guix system vm ...`, but i get "warning: call to primitive-fork while multiple threads are running;" and my code hangs somewhere. i'm not sure what i'm doing, and whether my expectations are valid... but i think that with-extensions shouldn't be needed.
<mirai>what's this thing about 'closure size' and how do I measure it
<AwesomeAdam54321>mirai: Closure size is the size of a package in question and all it's dependencies. It can be calculated using guix size
<apteryx>moving the conversation to #firefox, as it's off-topic here
<yewscion>Quick packaging question: If I define a new package as a variant, do I then need to redefine all packages that depend on that package so that they will build using the variant instead? Example: If package "foo" is dependent on package "bar", which is currently version 1.0.0, and I define a variant of the package that is version 2.0.0, will I then need to define a variant of foo that explicitly uses that input?
<lechner>apteryx / i'm not sure how broad the FF definition is, but going across origins can be an extremely risky thing for phishing and cross-scripting atttacks
<yewscion>AwesomeAdam54321: Copy, thant makes sense. Better to define a variant, then. Thanks!
<apteryx>lechner: the server simply fails answering, even when the CORS passes
<PotentialUser-34>Hi. Finally my Honeycomb Lx2 board arrived at my brothers shop. It will be assembled soon. micro usb access already works. Would be nice to have some guidance how to set up it as additional build machine for aarch64
<rekado>PotentialUser-34: the maintenance.git repo contains the Guix System configuration we use for our honeycombs
<rekado>it does not, unfortunately, contain more information about what to put on the microsd card to get it to boot up at all.
<tschilptschilp23>Have there been any changes to the derivation process? Pretty cool, I forgot to run 'guix weather' before checking, if ungoogled-chromium is available as a substitute, and my computer's RAM seems to be left in peace (other than a year ago)...
<tschilptschilp23>nckx: thanks for the hint, this made me C-c C-c now. Actually a minute ago guix weather reported ungoogled-chromium as ready, but when I started my reconfigure, it wanted to build again. Pulling right now to see if changes have arrived, but speed's down at 26KiB/s (but that's been for a while now here). Let's see, maybe I can save some time anyway.
<rdrg109_>ae_chep: Thanks! That's the one that I've been using, but it requires downloading something from the Internet, and I would rather downloads from external sources didn't occur.
<nckx>tschilptschilp23: I think the fact that Guix reports seeing a substitute but then doesn't actually download it is the symptom of this bug. If .drvs differ between code paths, that could happen. In fact most bets are off at that point.
<ae_chep>can a channel be served off of a filepath?
<ae_chep>rdrg109_: You could copy the sources to a local directory, and edit the file description so it's url-fetch method and the uri is the absolute path to where the pkg is
<ae_chep>nckx: by the way, with this "filepath" pointed channel setup I was able to finally feel some calm after having spent hours trying to get the guix shell recognise my unpublished packages. So, genuinely, thank you for the answer and help. I feel so relieved now...
<ae_chep>*packages whose changes have yet to be accepted upstream
<nckx>Thank you! It's the same set-up I use myself. Just don't forget to commit, Guix still won't see uncommited files :)
<ae_chep>they are committed alright! They just need a maintainer to accept the changes
<rdrg109_>ae_chep: Ok, I'll try that. I can see that in the my-hello package example. The URL starts of the downloaded file is "mirror://gnu/hello/hello-2.10.tar.gz". Do you know how I can use "wget" on that URL? If I use it as it is, wget shows the following error => mirror:/gnu/hello/hello-2.10.tar.gz': Unsupported scheme: 'mirror'.
<winter>unmatched-paren: would a patch to correct that inconsistency be accepted? i feel like that would probably be a good thing to have (as in, a 1:1 mapping of package name to canonical import path)
<apteryx>nckx: haha! an info target in the kernel doc! how heretic
<cbaines>winter, first the data service (at data.qa.guix.gnu.org) has to process the revision, that works out what's changed. Then if there are packages that have been changed, those need to be built to determine if any packages have been fixed/broken
<ellysone[m]>For anyone running guix in production, How often do you have to to think about cleaning the previous generations and all of that? Do you have some custom code to take care of that?
<nckx>tux_life: ‘I don't think the ram is faulty’ is a big claim when something called ‘memtest’ fails 😉 Note that ‘bad RAM’ doesn't mean your stick is rubbish: multiple folks have suggested you take it out, give it a good dusting, and put it back securely. Have you?
<nckx>(Including someone in #libreboot but you'd already left.)
<nckx>I see Leah's there now. I suggest listening to her, this is not a Guix issue.
<tux_life>@nckx The problem remains with 2 laptops...
<nckx>tux_life: So this failure has *something* to do with your configuration: it happens on my machine as well! Pretty sure it's because your login-service-type, which duplicates the one already in %desktop-services.