<wdkrnls>I just thought it was possible that maybe you were confused about the difference between your profile and the system profile and I could be of some limited assistance.
<wdkrnls>However, probably I am the one who is confused about guix system related things.
<apoorv569[m]><wdkrnls> "Where are you looking for that..." <- I used `guix system list-generation` command to see list of generations
<apoorv569[m]>BTW the system.scm file has an operating-system definition which inherits from base-operating-system defined in base.scm file
<apoorv569[m]>so I wanna have like per system configurations and a base system configuration
<apoorv569[m]><wdkrnls> "The file you showed suggests..." <- Yes.. it uses I am missing (gnu channels) module because of the variable `channel` being used ..
<apoorv569[m]>but I am not using channel anywhere either base.scm or system.scm
<wdkrnls>Sometimes dependencies can be tricky. It is preferable to bring in too many dependencies than too few.
<wdkrnls>However, it sounds like that is not your main issue.
<wdkrnls>Can you point me to the manual where you learned you can use ~/.config/guix as a folder this with `guix system'?
<wdkrnls>My understanding is that folder is reserved for your user profile.
<wdkrnls>That said, I cannot say I have the best setup. I just sudo rsync my config.scm and supporting files to /etc whenever I update it.
<wdkrnls>I think you should just have one config file which serves as a point of entry.
<wdkrnls>I would imagine it would be your more specialized file which you would modify to be sourced when loading your specific features.
<apoorv569[m]>I think its not supposed to be like that I mean files under ~/.config/guix
<apoorv569[m]>but I use -L flag to specify load path so it can read my custom defined module that is in base.scm file
<wdkrnls>I like the general idea of abstracting out shared functionality for managing multiple computers.
<wdkrnls>I haven't done it before, but I think my point of entry would be config.scm and it would just be generalized with procedure calls which tested what system was running and returned the apropriate configurations based on that test.
<wdkrnls>I like this `guix system playground' topic in the manual.
<wdkrnls>If I had a faster computer with a properly functioning hard drive, I would love to try it out and experiment.
<wdkrnls>If you haven't done that, maybe have a look.
<wdkrnls>Why do you need to be running system level configuration as your user?
<apoorv569[m]>Yes the /etc/config.scm works.. because it is installer generated.
<apoorv569[m]>I am not running system level configs as my user.. sudo -E uses my users environment as in files and channels list and env vars from user but being a command ran with sudo it changes the system
<apoorv569[m]>you can put channel.scm file in ~/.config/guix and do guix pull without sudo
<wdkrnls>That is what I am scared of. I use Guix predominantly to avoid all this crazy mixing of environment variables which happens on other operating systems.
<wdkrnls>It is just too hard to understand. Guix helps me isolate things.
<wdkrnls>I suggest trying to use that strength to your advantaged.
<wdkrnls>I thought you could also place your channels it etc as well?
<apoorv569[m]>I mean it is "hard" ATM for me because of low understand of Lisp language but not hard as in process .. I hope it makes sense.
<apoorv569[m]>I always wanted to learn a lisp dialect.. Using Guix gave me that opportunity.
<jonscoresby>What is the timeline for patches to be reviewed and merged?
<apteryx>if it shows green in the QA and followed the conventions outlined in the Contributing section of the manual, it can be rather expeditive. But it remains subject to the availability/interest of the reviewers/committers, which are all volunteers.
<apoorv569[m]>I got the config working... there were some errors in the config..
<jpoiret>most languages which don't heavily rely on their own homegrown package manager
<mekeor[m]>drakonis: i know but i'm interested in the present time :)
<pkal>jpoiret: doesn't python rely pretty heavily on pip?
<pkal>then again I recall that package management with python is a mess, isn't it?
<jpoiret>it does, but since it's an interpreted language we can still manage
<jpoiret>for compiled languages that need their own build tool and package manager it's more of a nightmare
<pkal>what does that have to do with being interpreted or compiled?
<jpoiret>the problem is often that the custom build tool for compiled languages operates on a set of assumptions that are broken by Guix, or that are very hard to uphold without sacrificing the Guix model
<jpoiret>for interpreted languages you don't have those build tools when you're actively writing code
<jpoiret>that might be an oversimplification, but I guess that's how I could explain why Python still works well on Guix
<dlowe>I'm trying to fix tcl's search-path definition and I'm pretty sure I have it where it'd work but I can't figure out how to test this in isolation.
<jpoiret>it only needs to know where the .py files are, not compile crates that live in some cache directory into some other binary artifact directory that only the build tool understands
<pkal>that was my question: What are the assumptions that are broken by Guix?
<jpoiret>for rust: distro-provided crates in specific directories rather than a global mutable cache
<jpoiret>for go as well, those languages really want to be the sole tools that can provide and access dependencies
<mirai>is the naming of guix service symbols such as 'networking 'user-homes 'user-processes 'file-systems deliberate or was it just author's preference?
<lechner>mirai / Hi, do your NFS clients shut down properly? (I have had that issue even before I started using your delayed networking trick.)
<mirai>lechner: what do you mean by shutting down properly?
<pkal>mirai: ok, but a language like C shouldn't be affected by this?
<lechner>mirai / i have to unmount manually before a shutdown succeeds
<mirai>hmmm... Did the system just never power-off?
<mirai>I've noticed this too, often reboots or shutdowns either took too long or never powered-off
<nckx>mfg[m]: Package ‘specs’ (as used by the CLI) always default to the highest matching version, so we can't return a lower ‘default’ version without making things confusing & messy. But you could do so under a different name? ‘guix-build-system-gcc-toolchain’; name to be bikeshed at will :)
<mfg[m]>nckx: thanks for the explanation and suggestion :)
<unmatched-paren>ACTION sent v6 of dissecting guix part 2, hopefully to be the last :)
<apteryx>I sometimes get "In procedure mkstemp: Permission denied" in Geiser; any remedy? I think I must have changed my /tmp permissions by mistake?
<nckx>dlowe: It's not as scary as it looks. (@ (some module) foo) simply means ‘the exported variable foo from (some module)’. It's a self-contained way of writing ‘(use-modules (some-module)) foo’ without actually importing the entire module into scope.
<nckx>dlowe: But really, this was all a bit of a ‘this is how you *could* emulate a guix.scm’ tangent :) I myself would, like unmatched-paren, simply use ‘guix shell [-D] PACKAGE-NAME’ directly, where the package might be ‘guix’.
<mirai>but I suspect the annotated link has changed
<mirai>because Ctrl-f for appliance doesn't yield that sentence
<nckx>No, it's a very old discussion [I did not mean that the discussion itself was invalid! Only this parody of it] and nmap has been dragging their feet on clarifying matters, possibly for reasons beyond their control.
<mirai>no value in knowing that 'fantastic-but-unbuildable-package' provides '%/bin/cure-for-cancer' or '%/bin/undo-pandora-box'
<lechner>surpador / i am looking for folks willing to run the client locally. (one-off for now.) it collects limited information about the folders in your /gnu/store such as relative paths, file types, permissions as well as input and output hashes
<mirai>lechner: why not ask $guix_member_who_manages_substitute_server
<lechner>but no hashes for individual files, in order to maintain some level of privacy and plausible deniability
<lechner>mirai / i may, but they seem pretty busy. i also do not have a nar importer yet
<mirai>that approach is sure to yield garbage data
<lechner>that's something for the core devs to decide. i believe that our directory naming scheme in the store could be improved, but for the time being i have more than enough disk space
<mirai>you could think on quorum-like countermeasures but they're also defeatable and highly complex
<mirai>at the end, you need to trust whoever provides the substitutes (or store)
<lechner>sure. by the way, that argument has often been used against Debbugs but to my knowledge no one has tried to mass-close all our bugs
<surpador>As long as you still only use trusted substitute servers, that doesn't seem like too much of a problem, right? The index might simply misead you, but you'd be no worse off than you were before it seems
<mirai>I think this is up to the project/ML manager to decide on the available permissions
<surpador>lechner: at the moment I only use a laptop, so not sure how useful it would be to run on my computer
<mitchell>Hello guix, I am trying to build linux-libre with different source but the configuration phase keeps failing saying `include/linux` has conflicting types to glibc. How can I get it to use a toolchain using the headers from my sources?
<apteryx>which version of gtk provides webkit2gtk-4.1?
<lechner>jpoiret / it's not based on files but on folders in /gnu/store. i used no file-level hashes (for privacy)
<jpoiret>ah, right. Still gotta track if those derivations come from the same guix version, but that's a nice idea
<lechner>akm / i think those messages are unrelated to your crash
<nckx>akm: OK, so none of that looks directly relevant (although the hint that gdm is started is interesting, since that doesn't look like GDM!). Most people would not call this a ‘crash’ which doesn't help confusion. Can you switch consoles with C-M-F2, for example?
<nckx>akm: So this system has not been changed in any way since it was last sucessfully used?
<mekeor[m]>does build-time native-compilation of emacs-packages work for emacs-next? could anyone, who has emacs-next installed (preferably on guix system), execute the following, and paste its outputs for me? for d in $(echo $EMACSNATIVELOADPATH | sed 's/:/\n/g'); do echo $d: $(ls $d); done
<mirai>motherboard sag, thermal cycles, heatsink too tight, etc.
<nckx>mirai: Is that deleted test really useless for anything? Is there nothing of value to salvage? (I don't know.)
<mekeor[m]>investigating a little further, e.g. i have the emacs-posframe package installed, but /gnu/store/...-emacs-posframe-1.3.2/lib/emacs/native-site-lisp/ only contains a directory starting with "28", not "29" or so
<nckx>ACTION checks which store items, if any, even have a lib/emacs/native-site-lisp…
<andreas-e>You see your lovely patch on top of something that is tagged as "base-for-issue-61536" and several others./
<lfam>nckx: I remember that it efficiently offered a Git-based model for analyzing the effects of code changes on build results. You could easily compare arbitrary commits, branches, etc, and then view and filter the relevant results, including build logs.
<lfam>It would show the results of *all* builds required to effect the change, not just some arbitrary-seeming list of builds that happened to performed as a result of a job.
<lfam>And it did not conflate or combine build logs from different derivations
<lfam>Basically, it did what you wanted. Of course, memory is rosy, but I don't remember saying often "I wish it could do X"
<lfam>I don't remember for sure, but I think it would perform new builds per-push, which is nicer than what CI does now, which is periodically
<cbaines>lfam, so the "blocked" count is counting builds that can't start because some dependency fails to build
<lfam>Right, makes sense! I figured it from one of your emails :)