IRC channel logs
2025-04-24.log
back to list of logs
<isf>that word "pull" you are speaking about a decision? <isf>Im speaking just about the word "pull" <lfam>What's your native language isf? <lfam>Is there anyone here who can help isf learn about `guix pull` in Spanish? <isf>im trying to translate that word into spanish, but Idk what you are literally trying to say <ieure>isf, Have you used the Git version control system? <isf>I dont care about guix pull <isf>I care about of the word pull <lfam>I see. It means something like "decide which version to use and acquire that version" <isf>the usage and the meaning of the concept of "pull" on that context, the techical issue is not so important to this issue <lfam>Sometimes you download it, sometimes you don't have to download because you already have the version <isf>But why you call it "pull" <lfam>You could also say "decide which version to use and make that version effective" <lfam>isf: Because it's the same terminology as Git <lfam>And it's built on top of Git <isf>ooh ok is terminology of Git, thanks lfam <lfam>Conceptually it's different from Git. But it's hard to choose the perfect name for things <sham1>Guix doesn't have a concept of a fetch as separate from a pull <sham1>Because that could be used to basically "pre-download" the new stuff and then be pulled later offline <isf>you can find some relation <isf>with the pull concept as a word and relation with git <isf>with the words "come from, derive from"? <isf>Home environment in guix can be called user environment? <futurile>isf: Unlikely. Home environment is literally the users personal configuration, consisting of all files that are kept under $HOME. Most likely a "user's configuration" <futurile>hope it helps - writing/translating is hard! <isf>" set up and operate build offloading " <isf>that build is related to compiling right? <isf>I already finished the translation of GNU Guix <meaty>Origin patches are always applied right after unpacking, right? so patches to files generated by bootstrap have to be applied in a phase <isf>\o/ thanks futurile lfam <isf>I translate the whole website for spanish speakers \o/ <meaty>oh cool! thank you very much <isf>and I started to translate Guix <isf>Guys what you mean for you when you say: " perform download described by fixed-output derivations " <apteryx>lilyp: hi! how do you see the calendar errors as shown in #78015? do you need to run 'gnome-calendar' with some debug flag? <isf>what is a fixed-output? Is that like a fixed-date or like a fixed-problem? <apteryx>fixed-output means the output is known in advance, IIUC <isf>IIUC? apteryx can you explain? <apteryx>such as for a tarball, if you know it's hash, you can trust that if you download that tarball and it hashes the same, the output is trusty <isf>like a output everyone know? and can not change apteryx ? <isf>is like something trusty thanks <isf>oh yes that was what I tried to said <isf>my hands are slower than my mind <meaty>is there any preference for a VC repo vs. tarballs if both are available? <meaty>will tarballs limit the capabilities of guix refresh? <ieure>meaty, Just my opinion, but repo > tarball. <ieure>`guix refresh' will scrape web pages to look for versions, but looking at tags in the repo is more reliable. Though Guix's detection of which is newer isn't always <lilyp>apteryx: just from command line <xelxebar>Man, git.savannah.gnu.org keeps 502ing on me. <attila_lendvai_>and catching errors and turning them into ephemeral stdout messages of "failed to unmount '~a': ~a~%" is very bad practice. error handling in guix (and shepherd) needs a lot of love before they stop being a sink for avoidable debugging time... <futurile>To vote you have to be in a Guix team - if you're not in one yet you can send a patch :-) <nikolar>don't tell me that the branch name nonsense is still a thing <futurile>nikolar: well time to vote on it then, and make sure your view counts <apteryx>what does 'cat /sys/power/state' show on your machine? do you use guix system? <clone>is there a way to keep the build dir for a successful build of a package? e.g. to help with fixing issues with install. Right now I just use -K and add a phase to intentionally make the build fail at the end <apteryx>clone: that's what you have to do, yes. there's no easier way. <futurile>apteryx: Ubuntu (22.04), -> freeze mem disk <apteryx>I wonder what happens if you write an invalid value there such as 'standby', which is what our elogind config would cause it to do, for the 'suspend-state' option (it is using 'mem standby freeze') <apteryx>I guess laptops typically support 'suspend' rather than 'freeze', which is better at preserving energy. <untrusem_>my laptop just goes into deep sleep or hibernation when I close the lid, I had to force shutdown it sometime to get to the system again <apteryx>what would you want it to do instead? <adanska>where do treesitter gramars get installed to? vhdl-ts-mode isnt able to find the treesitter grammar, even though i have tree-sitter-vhdl in my profile <ruther>adanska: to the profile you install them to. You need the tree-sitter base package in the same profile to get the env var TREE_SITTER_GRAMMAR_PATH. And you will of course need to relog/source the profile manuially to get it working in programs the first time you install tree sitter. <ruther>adanska: but that goes with any new search path, not just tree sitter one. <ruther>adanska: no, sorry, you don't need to install tree-sitter, the search path is actually included with Emacs <adanska>ruther, thats strange. would there be another reason emacs cant find the grammar? <ruther>adanska: yes, the one I explained higher up <adanska>ruther, both emacs and the treesitter grammar are in my home profile.. <identity>adanska: does restarting Emacs not help? <ruther>adanska: I was talking about relogging to get the env var <csantosb>futurile: which makes me wonder if keeping a guix.gnu.org/manual/devel/en and a guix.gnu.org/manual/en makes sense, since guix is rolling release and we advice to do a `guix pull` right after install. <csantosb>I mean, we are always supposed to refer to the guix.gnu.org/manual/devel/en one, right ? <identity>csantosb: there is probably a bunch of users who stick to releases though <Frenchnewbie>hello, can someone help me understand how "inclusion" works please <Frenchnewbie>i would like to split my config file and call the files needed depending on the system i call it <identity>Frenchnewbie: (info "(guile) Local Inclusion") <futurile>csantosb: yeah, it's a good point - after your first update you're basically on devel anyway! <identity>Frenchnewbie: you possibly want to use (info "(guile) Using Guile Modules") instead <futurile>csantosb: personally I would love it if we could manage a slow moving branch like Nix or OpenSUSE 'slowroll' <Kabouik>futurile: RE GCD003: Woah, I think this is the first time I see such tension in a Guix issue. Interesting. I would have thought moving away from "master" would have been close to unanimous. <csantosb>futurile: the rolling release model is fine (and simpler), as manpower is limited; more sophisticated release strategies require investing time on it <Kabouik>(Sorry, I didn't mean to bring the debate here by the way, please disregard my comment; I'm just surprised it turned out that way but that's interesting.) <csantosb>futurile: But, thinking of users using latest guix release, or installing on top of foreign using local package managers makes me worry <nikolar>Kabouik: why would it be unanimous though <nikolar>to be honest, i am surprised there are people who still care about that <Kabouik>No reason, wrong assumption from my side nikolar. I'm reading the arguments from either points of view and I don't disagree with all of them, hence why I'm saying that it's interesting. It's more nuanced than I would have thought before putting proper thinking to it. I still know what would be my preference, but I understand better the mixed opinions and I like that they all are meaningful. <Kabouik>Speaking of, I voted before realizing I was not eligible. Sorry. <Kabouik>This reply was not to my message, but I read it after I sent my vote. :< <nikolar>i assume they have some way of filtering invalid votes <Frenchnewbie>based on what i could understand, all i have to do is define a module and then call it from another file <identity>Frenchnewbie: you can add -L . to guix invocations to add cwd to the search path <Frenchnewbie>does it goes on the same line as #use-module or am i misunderstanding ? <futurile>Kabouik: straight forward to become eligible - join a team ;-)) <identity>Frenchnewbie: no you add it to the guix invocation like `guix home build home.scm -L .` <identity>Frenchnewbie: the important part is `guix -L .` <futurile>Frenchnewbie: are you trying to specify this IN a file, or on the command line? <futurile>Frenchnewbie: you asked about the Scheme 'include' function originally, so that's why I'm asking <Frenchnewbie>i was trying to understand how guix or guile knows where to look for when i put `#use-module my-guix config` in my config.scm <futurile>Frenchnewbie: OK, that's not the "include" function that you asked about originally. So you can ignore that ;-) <futurile>Frenchnewbie: you need the modules section of the Guile manual <Frenchnewbie>but does it crawl the whole file-system or just subfolders of root config.scm <futurile>Frenchnewbie: yes, it has a predefined list of locations where it will look for the manual. <futurile>Frenchnewbie: not the whole file-system, it looks in some special locations (see manual page), and the stuff in the brackets of your # <futurile>Frenchnewbie: not the whole file-system, it looks in some special locations (see manual page), and the stuff in the brackets of your #use-module tells it where to look for a local path (my-dir module) - which is my directories and modules have to be the same. <identity>(info "(guile) Load Paths") is of interest <futurile>And what identity was telling you is how to add a directory to the special load paths that Guile uses. <Frenchnewbie>does (info "xxx") is a command or just a quick way to tell me to google whats in the "" <sham1>It's the function call in Emacs <sham1>If you evaluate that form, you go to the info page <identity>you can quickly open the info page in Emacs with C-x C-e with the cursor right after it <sham1>Of course, this is assuming erc or rcirc or similar <Frenchnewbie>i only use terminal if i know a sed command can be quicker or specific CLI tasks <Frenchnewbie>so if i understand correctly about the load path, if i call `guix system reconfigure /home/user/guix/config.scm` and then in that file thers a bunch of `#use-module my-guix xxx` it will search for the modules definition in `/home/user/guix` and all subdirectories without any futher specifications ? <ruther`>Frenchnewbie: no, it searches all load paths with /my-guix/xxx.scm appended, it doesn't search all subdirectories <Frenchnewbie>So if in my `/home/user/guix` i have system, user and packages folders, i have to call files that are in them with `#use-module system system1` or `#use-module packages net-packages` for example ? <ruther`>Frenchnewbie: your location with guix config is not added to load path. you need to add it, like with the flag you are mentioning or with add-to-load-path <sham1>direnv is also helpful here, because you can then do something like `GUILE_LOAD_PATH=".:..."` and get the thing into the load-path that way <Frenchnewbie>would `add-to-load-path .` be sufficient to make my config portable ? <Frenchnewbie>i'd like to be able to load it from a usb stick the same way i would from my /home/user/guix <sham1>Unfortunately that's not really possible <sham1>Because when you're using the config from the USB stick, you need to add the stuff to the module path again <ruther`>Frenchnewbie: I dont know what you mean by portable here. I dont know what is not portable about the first approach. <ruther`>Frenchnewbie: you can of course add load path from within the scm, like the modules folder next to the config, as long as you add it before you use modules. It will work well only if your config is not a module by itself, though. <Frenchnewbie>from my pov, portable would mean that i could clone a git repo with all my files structured like <Frenchnewbie>and just make guix system reconfigure "whereveriam/guix/config.scm" <sham1>No, you got silenced due to flooding <sham1>Anyway, you can't do that. You have to add the current directory (or wherever you have your modules inside your git repo) into the load path. So you'd need guix system reconfigure -L whereveriam whereveriam/guix/config.scm <sham1>No, because you need the modules to be available before that <ruther`>Frenchnewbie: It does. Just add it at beginning of your config, before use-modules. <ruther`>Frenchnewbie: from your definition of portable I dont understand how any of the options would make it less portable. <ruther`>Frenchnewbie: you didnt get banned completely, but your messages didnt all go through. dont send many lines <Frenchnewbie>i thought splitting my config would prevent me from exporting it to another machine <futurile>Frenchnewbie: I think you're struggling with too many things at once. This is one of the downsides of the systemcrafters thing if you're new. <futurile>Frenchnewbie: putting your config in git as they show you makes sense. <futurile>Frenchnewbie: but you'll always have to (a) understand how to use modules (because you're splitting it) (b) tell the guix commands where those modules are <futurile>Frenchnewbie: there's some nuance around this, so going through the sections of the Guile manual on load-path and modules will help you figure it out <Frenchnewbie>i tried to stick to guix manual as much i could, i'm discovering Guix and Guile from scratch <Frenchnewbie>i came across systemcrafters when looking on how to split config and other questions i had <futurile>exactly, it's a lot all at once! personally I just cut-n-pasted my config between my laptop and desktop for a while until I figured it out <futurile>if you have a lot of systems splitting makes sense - I just have a laptop and a desktop so in a way it's overhead - I could easily just use two files and cut-n-paste stuff across <Frenchnewbie>my steps so far were : install guix system, make different generations with different system packages, make a first gui generation, create all my dotfiles needed for sway waybar & stuff... my next steps are : split the config file so i can make it a bit modular (adjust users easily, different packages based on system/user, etc...), create my first <Frenchnewbie>home config, try to source all my dotfiles throught home config <Frenchnewbie>once i have all this i'll try to reinstall guix system from scratch and see if i can get my system "as it were" with just a reconfigure <Frenchnewbie>goal would be to integrate guix in my personnal and professional environnement <Frenchnewbie>so splitting would help me setup things easier based on where i reconfigure <identity>Frenchnewbie: pretty much, yes, though most people would start with trying Guix on their favorite non-Guix distro before considering Guix System <identity>jumping in head-first into Guile/Guix may be a little overwhelming <Frenchnewbie>i saw a lot of people complaining that guix would override the non-guix distro package manager or whatnot so i wanted to test it in a "controled" environnement before getting into mixed environment <futurile>your steps make sense. If you're going to split the config you _really_ need to read through the sections of the manual you've been pointed at - it's going to be confusing if you don't ;-) <Frenchnewbie>do you have any kind of "exercises" steps you could give me that would be helpful ? <Frenchnewbie>like for the first home config my first step would be to create a hello world file in my ~/ <futurile>I don't think anyone has done that, it's a great idea <Frenchnewbie>i'll come check if theres any exercices after lunch, thanks again <sham1>On the other hand, if one can persevere with it, then going straight to Guix System can teach a lot about how this stuff works <Kabouik>Regarding GCD002, would Sourcehut not allow dealing with both MR and email-based patches? My project are all one-contributor only so I didn't really have to deal with patches or MRs on sourcehut yet, and I have to say that I like the minimal interface but it's also very misleading considering how other forge interfaces have become domninant, so I probably simply have no idea of the significant limitations that could impair a big project like Guix. <ieure>Huh. If I `guix system roll-back' with no networking, it tries to updates substitutes and download bison, which it can't, so it fails. <ieure>But when I connect it to network, it doesn't do either of those things. Or if it does, it doesn't print anything about it. <ieure>Maybe? I'm switching from one system generation to another, everything both needs are in the store. <apteryx>jpoiret: I saw your patch for elogind, it's look good, but I'd rather use the main /etc/elogind/logind.conf and /etc/elogind/sleep.conf files (which would work, since our sysconfdir is set to '/etc', see the package def). <ieure>apteryx, It breaks in this exact way every time. If I give it networking and roll back, then take away networking and switch generations again, it tries and fails to download bison again. Shouldn't that still be in the store? <apteryx>and you haven't run 'guix gc' in between, just to be clear? <apteryx>then neither I understand what is going on :-) <ryan77627>Hi all, is there any command I can use to get the dependents of a package that would be rebuilt if I update another package? The manual mentions `guix refresh --recursive`, but I was wondering if there was a command more akin to `guix graph` that doesn't actually reach out upstream when determining relations. I need it to just output a list of packages, not graphviz or anything else like that. <ryan77627>agh, `guix refresh --list-dependent` I presume... Anyways, I am working on updating Nix to a newer version for those who use it since the older version is beginning to break some flakes. Any branch I should contribute to? (This may be more of a mailing list question, I have never made a contribution this big before here) <Frenchnewbie>I tried a simple split config and added (add-to-load-path ".") at the top of my config.scm but i get an error telling me reconfigure doesn't find any code for my module <Frenchnewbie>config.scm is at top level and the module called is (systems base) which is defined in ./systems/base.scm <Frenchnewbie>i tried changing add-to-load-path "." to "./systems" and "systems" and i still got the same message <identity>Frenchnewbie: there might be a problem with your systems/base.scm, try loading it with `guix repl systems/base.scm` <Frenchnewbie> define-module: unknown keyword or bad argument in subform (gnu) of #:use-modules <futurile>ryan77627: --list-dependent to show the packages that would need to be rebuilt (top-level ones). Then to rebuild for testing you can do: ./pre-inst-env guix build --no-substitutes --no-grafts --dependents=1 <package@version> <futurile>ryan77627: look in etc/teams.scm to check if the file you're altering is owned by a team - if it is you can cc them (and put against their team branch if they have one). <ieure>Frenchnewbie, "." means "the directory you're in when you run the command," not "the directory the file exists in" -- If your config is /etc/config.scm, that means you have to be in /etc to reconfigure. <Frenchnewbie>i did get an error message based on my (gnu) syntax after that <identity>Frenchnewbie: it's #:use-module, without the s at the end <Frenchnewbie>i can't make a call to a service or module i didn't explicitely called in my file even if i call it in a module <Frenchnewbie>i thought there would be a link done or some kind of parsing <identity>Frenchnewbie: that macro is in the (gnu) module <identity>so you need to add (gnu) to your (use-modules) invocation <Frenchnewbie>shouldn't it be "loaded" by the `use-modules (system base)` ? <identity>Frenchnewbie: it is 'loaded', but the bindings from the module aren't made available to code in this file <Frenchnewbie>is there a way to avoid making multiple calls to one dependancy ? <Frenchnewbie>or do i have to explicitely (use-modules (gnu)) everywhere i need something from it ? <identity>Frenchnewbie: i do not see a reason why you would want that, and do not know of any way that is easier than just importing the module <identity>so, yes, just (use-modules (gnu)) wherever you need it <identity>Frenchnewbie: it seems fine from what i can see <identity>Frenchnewbie: because i missed the part where you did not import (gnu) but still used macros from that module <Frenchnewbie>that means theres no way to declare it in just one file for then all files that imports the one where (gnu) is declared to use it ? <identity>Frenchnewbie: no, i am not aware of an easy way to do that, apart from using include <Frenchnewbie>including a file and calling a module don't get the same results ? <identity>you technically could make a common-libraries.scm file and then add (include "common-libraries.scm") to the top of every scheme file <identity>Frenchnewbie: include just inserts the contents of a scheme file inside another scheme file <identity>while modules is a proper module/library system, with namespaces and all that <Frenchnewbie>i don't understand the "namespace and all that" but i kinda get the difference <ieure>Frenchnewbie, I set up my own channel and put all the common system config stuff in there. <ryan77627>futurile: Thanks for the insight! I'll do that later today. I already sent something to the guix-devel ML but I have a feeling it did not go through, which is fine since I sent that before seeing your reply. <ieure>Frenchnewbie, In my system config, I use the module: ((atomized system profiles) #:prefix profile/) and then (profiles/+profile (operating-system ...) (list +thinkpad +podman ...)) <ryan77627>Oh,,, this may take a while. What if `guix build --no-substitutes --no-grafts --dependents=1 {package}` contains something in the order of thousands of packages? o_0 <Frenchnewbie>i remember you already sent it to me once, it just felt so advanced i got overwhelmed by it <ryan77627>I may need to set up a different computer to churn through these <futurile>ryan77627: you might try building a "representative sample" - if it's thousands then it's going to have to go to a branch anyway <ryan77627>futurile: Thank you!! Yeah, once I saw the number I knew it was going to go to a branch anyways. Will watch your video when I am home, seems you answered most of my other questions in it when I skimmed through it. <sham1>Making a channel for simple config stuff seems a) like overkill and b) very irritating with the workflow, since you have to `guix pull` things all the time. Even if you reference the channel in your local filesystem, the pulling can still get pretty old pretty fast <sham1>On the plus side, channels do make certain things nicer (like for example being able to use custom packages in manifest files) <futurile>yeah pull makes the overall dev experience of Guix annoying - the cycle time is so long <sham1>That's one thing I think Nix does better in that regard. Packages and modules can refer to each other just based on being relative to each other on the filesystem (helpful for eg. flakes). Guix is a bit clunky on that, but I suppose that's one part due to using a real (and more importantly, general) programming language for this <csantosb>What about 'guix build -L /path/to/file.scm' ? <sham1>Well in general you'd have to add your whole guix config directory into the load-path because you might have packages there that refer to each other, <sham1>It's absolutely doable, but it's a bit of a UX papercut <sham1>Also, savannah seems to be having a bad day again <futurile>I basically land-up using a bash alias so I don't have to retype stuff all the time <ieure>sham1, Savannah has a bad day every day these days. <sham1>I've gone through the rigmarole of setting up a channel, doing the authentication and all that to see how that process feels like for a basic config needs, and it really is an ordeal if you want to do what the vast majority of users might want to do, which is maybe define some packages and services to factorize a config (esp. if one wants to support a fleet of machines) <sham1>Not having a channel means that you of course can't `guix package -s` the package, or `guix package -i` or whatever. Instead requiring the explicit use of the build-command, and then you need to mess about with the load-path and such. As said, it feels like a papercut in the UX <futurile>I think there was a discussion about a new command on guix-devel recently <futurile>the use-case was basically keeping some custom packages <csantosb>sham1: Out of curiosity, where is the problem with $GUIX_PACKAGE_PATH ? <sham1>I mean I guess nothing really, since that would work. It just like, feels wrong y'know <sham1>That's mostly just a me-issue though <csantosb>Asking because I keep a /tmp/chnl/csb.scm file, and I have $GUIX_PACKAGE_PATH pointing to /tmp/chnl <ieure>Does anyone have any visibility into what's been going on with Savannah? It's been super unreliable lately. Who's responsible for it, do they know? <dstolfa>ieure: if i had to guess, llm crawlers like every other project <ieure>I just have no idea what's going on with it and am wondering whether anyone actually does. <ieure>The issues this week and last have had a serious negative impact on Guix. <futurile>ieure: I follow GNU on mastodon, and there is a Savannah mailing list you can follow <futurile>ieure: I haven't seen any 'new' mentions of them being flooded this week, but they always seem to be under attack <futurile>ieure: check out the mailing list, maybe they are discussing it there - agree it's been bad again <ArneBab>would be great if you could merge it quickly. <ieure>Savannah's up for now, everyone pull :) <ieure>Someone want to try reproducing a simple issue for me? Just run `mumi am --help'. <sham1>bash: mumi: command not found <sham1>(Probably not the output you were looking for :P) <sham1>Oh, it seems to crash with a backtrace and at the end there's a line "In unknown file:" <sham1>Hmm, guix system reconfigure seems stuck. Annoying <sham1>In fact everything about this little VM image seems sluggish <untrusem>I haven't packaged before, so any heads up would be appreciated <untrusem>but It takes a commit hash, I would like to make it so that it automattically builds on the latest commit <luca>Hi, I'd like to ssh into the installation media. Does anyone happen to know the default username and password? <identity>luca: you can probably login as root with no password <identity>luca: (info "(guix) Manual Installation"), specifically § 3.6.1.2 Networking, should have more information <luca>ok so I have to set the password <luca>as I sit here and wait for `guix pull`, does anyone have an easy answer as to why guix needs the whole git repo of channels? as opposed to a shallow clone <ruther>luca: it's necessary for checking all commit signatures. But there is no shallow clone support even if you are using a channel that doesn't sign <luca>Ah, makes sense. Thanks! <luca>And how often does my local guix copy check commit signatures? <ruther>luca: the signatures are checked on pull <ajarara>is embedding the development manifest of a package (say, llvm) into an OS enough to make it so that it doesn't reach out to the network for a from-source build? Would I be able to turn off the network for the entirety of the build? I'm doing non-serious performance testing. <ruther>ajarara: during the build guix doesn't use internet at all. The internet is used just for downloading the source <ruther>ajarara: So building the source beforehand is enough to not use the internet at all (provided that you use --no-substitutes ofc) <ajarara>right, I'm talking about top level invocations (I'm booting up a qemu image across a variety of substrates, running the build, then tearing it down) <ajarara>so like the entire run, not just the build phase <ajarara>I'll see if it works and if it doesn't I'll be back with why <ruther>ajarara: I don't understand what you mean by that. No phase is using internet in normal derivation, the only derivations that use the internet are fixed-output derivations - sources. <ajarara>ruther: ah, yeah, so I think the answer is yes to my question: grab development manifest + source of llvm. <podiki>futurile: I saw scons was updated, is there a reason for the 4.5.0 version and not the latest? do you know of any regressions after that update? <futurile>podiki: no reason for that version, particularly (it was the version in the patch) - "they" had been working on python-team for a while, so I just helped out to merge/fix things and only changed things that "fixed builds". <luca>kinda silly question, how are you supposed to install a guix system from an existing config file? Are you supposed to `guix pull` first, then edit the config.scm? Or is there a step I missed <ruther>luca: when you edit the config.scm is irrelevant. Whether to guix pull is completely up to you, and also depends on what version of guix the iso has, ie. you probably want to pull if it has an old one. <ruther>luca: you install as you would do with an initial config, it doesn't matter - just guix system init after mounting everything <luca>oh. I just followed the installer and edited the config at the very last step <luca>is there any faster alternative to guix pull? I don't want to update packages on the live image, I just want it to install the system from newer sources <ruther>luca: guix pull doesn't 'update packages on the system' <ruther>luca: there really isn't a faster alternative <luca>oof I see. I'll try again tomorrow armed with new knowledge and experience I guess <podiki>futurile: ok thanks. just seems very odd since that is 2 years old release <podiki>futurile: getting a very odd build failure with godot post python-team and no idea why (it is within its contained third party stuff, and there are no direct python dependencies, so.....????) <sham1>luca: guix time-machine -C channels.scm -- system init /mnt/etc/config.scm /mnt <sham1>And same with guix system reconfigure <ruther>sham1: that will do the same thing as pull, worse yet if you need to rerun because of errors you will wait for longer <ruther>'same' as in build the same thing <sham1>Sure, but at least it's one command instead of two ;) <sham1>The real problem is that you can't avoid pulling. *Maybe* there's a way to build an ISO which has "already pulled" the given pinned revisions at build-time, but I at least couldn't figure it out <ruther>sham1: there definitely is, you just override the guix in guix-configuration of the guix-service-type <ruther>sham1: for example, you can use (current-guix) to use the the on you're calling `guix system image` with. Or you can use guix-for-channels with the default guix channel specification to get the latest. <luca>What does `guix pull` _do_ though? I'd assume it just `git pull`'ed stuff, but obviously it's started building as well <futurile>podiki: let me see if I can find the series I was looking at. <ruther>luca: the guix modules are compiled <futurile>podiki: you want to try reverting it, or moving it up if you think it's the cause of the godot failure? <ieure>luca, It updates the guix binary. <podiki>yeah that's what i'll do next locally, try with latest and try with previous. no idea if that's the issue it is a linking issue <podiki>not even sure how many packages use scons to build either <sham1>ruther: hm. I may have to try that next time I build myself a custom ISO <luca>Maybe I'll look into generating my own image given how slowly it's going. /shrug <ruther>ieure: there isn't a guix *binary* <ieure>ruther, Hmmm, I assumed the Scheme got compiled, but you're right, it's a Guile script. <ieure>It updates the guix command. <ruther>ieure: yeah, just the modules are compiled <ruther>sham1: see gnu/system/install.scm under guix repo, it uses the guix in guix-configuration with (current-guix) <sham1>Aight. I'll take a look. Could also get more than just the TTY prompts to work in (proper web browser and emacs? yes!) <ieure>podiki, The build log you linked the other day had a bunch of Python stuff in the output. <ruther>*Waiting for Godot to build again!* <podiki>ieure: the errors i saw at the end was linking, all from the included 3rd party libraries with references to other 3rd party libraries <ieure>podiki, Yes, I saw that. I agree it's puzzling, but the fact that the output has a ton of Python stuff printed means that whether it has a direct dep on a Python thing or not, the Python updates could be behind why it broke. <ieure>It's interacting with python stuff. <podiki>there's at least no direct python dependencies (i guess the scons build system?) but through some hops <podiki>yes i agree, just makes it hard when it's not clear what python stuff :-| <podiki>so my guess now is to check scons just because that is a direct input (and i see it has ~160 dependents so can be touched if needed on master) <podiki>godoto builds with scons 4.40 so must be some change to scons (perhaps some environment variable/directory it needs to see to do linking properly) <podiki>and builds with latest 4.9.1... maybe 4.5.0 was unlucky, will try last point release of 4.5 just to find out and then likely i'll update scons to latest after building all locally