<lilyp>Both. Users would have to compile everything and the build server wouldn't be that fast in catching up to the demands. That's why we push everything with a high rebuild count to feature or team branches rather than master.
<nckx>avalos: There is no support for ‘secure boot’.
<nckx>Unprivileged processes can't modify the store (which is where all Guix-managed files live; there is no ‘base system’), they can only ask the Guix daemon to modify it. Regular users can ask it to install or build anything, and collect any unreferenced garbage.
<nckx>bumble: Did you manage to fix your ‘guix pull’?
<nckx>The larger issue here is that (1) Guix tries very hard not to have an opinion and force it on the user (i.e., it doesn't parse options at all, and passes them verbatim to the kernel) (2) many people don't know that there's a difference between flags and options. So maybe parsing the option string and filtering out flags, removing the ones that mount(8) maps to flags, is the pragmatic option.
<nckx>mount(8) uses different names than Guix, though, but it is what it is.
<nckx>We could replace that with a list of strings that we then remove from options and stuff into flags. WDYT?
<nckx>But wonko-the-sane: Guix doesn't whitelist or parse mount options, you can use ‘discard’ just fine, but it's not a valid flag.
<pastor>good morning. Should `guix describe -p <path-to-profile>` give information about the channels used to build the profile?
<nckx>Currently? No. Feature request? …maybe. On first thought I think that's best kept under the ‘guix package’ namespace.
<pastor>nckx: Isn't this a bug? Because in 'emacs-guix' we rely on this information to provide info about the availeable packages. But if you have emacs-guix installed from a profile you will never get info about the channels
<pastor>nckx: The thing is that if you do `guix describe -p ~/.config/guix/current/` it does give info about the channels that compose the profile
<nckx>I don't know what the original intention was behind ‘guix describe -p $non_guix_profile’, to be clear, I'm just saying the current behaviour doesn't strike me as obviously wrong. I'm also not saying I'd oppose the change, if someone like Ludo' agrees.
<nckx>But if there was an intent to keep profile types + subcommands separate, I think it's a good idea.
<nckx>Does emacs-guix take a ~minute to start on your machine, pastor? Presumably not. It keeps me from using it more.
<pastor>No. It works pretty well. I'm using it for discoverability of packages. Super useful. Also I realy use a lot `guix-edit`
<pastor>Note that I'm using a patched version I have which fixes 'emacs-guix' not being able to build packages. I submited a patch to fix it a few days ago
<pastor>nckx: Regarding the thing we were talking about `guix describe` my concern is that 'emacs-guix' is internally relying on the `guix describe` scheme module. An there we have functions such as `current-channels'
<efraim>I'm pretty sure sdsl-lite can benefit from being marked tunable
<nckx>pastor: But it's using that to try to find out which channels went into a package profile? To me that does not jive with the description in (guix describe).
<pastor>nckx: Look. The thing that looks fishy to me is that if you invoke `current-channels' from a `guix repl` all works good and provides all the user channels. But if you invoke the same thing under a `guile` repl it does not list user channels. This is what breaks `emacs-guix` i believe.
<pastor>well the root of the problem seems to be that in a `guix repl` invoking `((@@ (guix describe) current-profile))` looks good but under guile it does not work _even_ if the guile repl is making use of the emacs-guix module
<pastor>nckx: for context the `current-profile' invocation is used in the `curren-profile-entries' procedure. If there is no current profile it just returns #f.
<nckx>Would you agree that emacs-guix is using the wrong interface, at least as (guix describe) is currently designed to be used? I certainly agree that the brokenness is unacceptable, but you seem to be implying there's a bug in (guix describe), which is either my mistake, or something on which we disagree.
<pastor>nckx: I agree that maybe `guix describe' should only be used to get information about the 'guix' instance
<pastor>Therefore the problems is that we are lacking an interface appropriate for the job
<pastor>Looking at `current-profile' procedure I see that the reason why we get the #f is because it is looking at which program invoked the procedure by means of using `program-argument'. So if it does not match a `guix repl' it simply does not provide the info it should
<pastor>We see this in the code of `current-profile': (string-suffix? "/bin/guix" program)
<pastor>nckx: So what do you think we should do about this broken implementation?
<pastor>Welp. It is not workig because in the case of using the `guix repl`. The guix program will be located in something like `~/.config/guix/current/`
<lilyp>why can't you invoke the guix repl normally?
<pastor>The thing is that since the guile repl program is been invoked with a path to the store the program argument looks like `/gnu/store/4gvgcfdiz67wv04ihqfa8pqwzsb0qpv5-guile-3.0.9/bin/guile` but wee need a path to the profile like `/run/current-system/profile/bin/guile` or something
<pastor>where a few levels up we would find the profile manifest. Resolving the symlink to the store breaks the implementation
<pastor>lilyp: i don't know about that one. The implementators of `emacs-guix` decided to use `guile` instead of `guix repl'
<lilyp>the arg0 to the guile script should still be guix if invoked correctly
<pastor>lilyp: It boils down to the value of `initial-program-arguments' defined in `guix describe' when using a guile reple this points to the guile executeble in the store. From a `guix repl` it points to `~/.config/guix/current/bin/guix' where a few levels above the manifest can be found.
<potato_lisper>Hi everyone. I'm having problem with upgrading my system. Getting this error constantly
<pastor>Which is defined (i guess) when the package is built and points to the store. If in the internal repl we set it to the correct path like so: (set! initial-program-arguments '("/run/current-system/profile/bin/guile" "--no-auto-compile"))
<wonko-the-sane>nckx: ah right, sorry for the equivocation thinko. Still wondering though is the distinction purely(/or mostly) a kernel-space one? I wonder what is gained by being less abstract than e.g mount(8), /etc/fstab?
<nckx>wonko-the-sane: Well, we don't wrap mount(8) or its configuration file so there was never a good reason to follow it. Keeping them separate allows us to at least validate flags. I'm not really a fan of my earlier suggestion to combine them, I think Guix is better off suggesting 'did you mean this to be an option' on failure.
<nckx>Actually I thought I'd committed just that change, once, but I guess not.
<nckx>The Linux list of flags is pretty static, Guix's list could easily be completed so that warning doesn't mislead users.
<mirai>I think I explained it in the commit message, let me confirm
<mirai>ok, I didn't but I recall the exchange I had with the author
<lilyp>In that case, I think we can do a three-commit series: 1. Use G-Expressions for xfig. 2. Add fig2dev and mark transfig as a deprecated package; adjust the description for texlive-latex-make in that commit. 3. Update xfig
<podiki>normally I'd blame things cropping up with root's cache or guix on using root's account for guix when just need sudo for system reconfigure only really; but I never use root's account and it happened so....
<bumble>it looks like nothing new is happening there just building the derivation
<podiki>we may be seeing slightly different things that went wrong
<bumble>doing system reconfigure now... and it is generating object index, something it did not do before deleting /root/.cache/guix and /root/.cache/guile
<jackhill>lilyp: podiki: I've run into that too (on two different systems). The first one I cleared it and moved on. It does seem like a bug though? I could preserve the cache on the second. Maybe using git instead of libgit2 will "fix" it.
<podiki>yeah, i think that means you made it past it, was an immediate error for me
<podiki>in all my guixing past few years i've never seen it before, how strange
<euouae>use-modules should allow for tree module imports
<bean123>Is there problem with Guix servers? connection to ci.guix.gnu.org timed out
<bumble>guix home is perfectly stable... I didn't really understand the purpose or usefulness of guix home before setting it up, but am very happy with using it here and would not go back to using a single system config again
<ulfvonbelow>I should have each system generation include the current guix used to build it. That way if I run 'guix pull' and then start building a new generation, and then it fails halfway through some long process, and later I need to change one little configuration detail quickly, I can just use the stored guix to get it done without having to first finish the big upgrade or try to roll back the guix generation.
<bumble>another good thing about guix... no more messing up your system and then having to chroot into it to try and ninja a solution for whatever issue
<euouae>who knows. for example, I can't get perf to work with a user account on debian. would I be able to get it working on guix?
<bumble>I don't about your perf things but _there is a way_ guaranteed... and once you have it setup and working with your configuration files, the problem of setting up your perf is basically permanently solved
<bumble>you can apply the configuration to another machine and whatever solution you have there, it will be applied there
<euouae>downdetector reports outages across the board
<mfg>lilyp: the backends are all transparent and only usable if the corresponding packages are actually found on the system, so i don't think that would be a problem. Unless you mean, the programs should be patched to make it impossible to use cude, but i don't think this is what you mean
<lilyp>I think this would fall within the real of advertising non-free software, so yes, I think any such capabilities are probably best removed – or if it's using a plugin-based solution the relevant plugins neither built nor installed and their sources snippeted away.
<mfg>another question: how exactly does `guix shell' invoke the shell that's spawned within? I'd like to find out the difference between `guix shell syncthing' and `guix shell syncthing -- syncthing' where the connection has been established via ssh
<mfg>because there seems to be some subtle difference