IRC channel logs
2023-09-24.log
back to list of logs
<vhns>I know this could be easily answered looking at the manual or something, but does GuixOS have any sort of integration with FSs such as ZFS/BTRFS/bcachefs? <vhns>I'm asking here more to see if someone has an experience/opinion to share <nckx>There's *support* for Btrfs and ZFS (and the Guix side of bcachefs support is there, too), but little ‘integration’. <nckx>Experience: I've been running Guix System on bcachefs for 4 years now. <nckx>(There is no bcachefs support in Guix's linux-libre packages, however.) <mekeor>nckx: wow, that's bad communication in that mail-thread, uff <nckx>It wasn't great. Good night! <jaeme>Okay I'm gonna log off now. My total between my channel's crates-io.scm and crates-graphics.scm is 7713 lines <jaeme>I'm still not satisfied though <jaeme>This tiny little type crate literally bundles in a game engine <jaeme>Rust devs showing us why they'll rule the world. <the_tubular>I'm a very beginner in rust, but what is blocking exactly that it's being hold back updates this much ? <lilyp>I mean bundling a game engine for a totally unrelated task seems like it'd complicate packaging a teeny weeny bit. <lilyp>the fact that switching to a newer rust is basically a world rebuild thanks to how widespread its usage is at this point? <lilyp>oh and don't forget that i686 still isn't supported, because why would one care about such architectures? <the_tubular>Here's another noob question, Why is world rebuild such a bad thing ? <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. <the_tubular>But yeah, I guess it would be still way more frequent than normal gentoo usage <lilyp>And yeah, it's not that particular to Rust, but the packaging dystopia is still very much its own (which takes hints from the npm dystopia, but also does some things differently). <lilyp>Gentoo manages to skirt around that by not propagating rebuilds. <lilyp>People don't tend to notice that until they use a functional distro like Nix or Guix. <the_tubular>Yeah, but that would kind of defeat the point of Guix ... <the_tubular>I also probably underestimate the number of packages that would require a world rebuild <lilyp>We can cheat like that as well (look at grafts), but Rust doesn't understand those because cargo only does static linking. <lilyp>ABI stability? What is ABI stability? – basically everyone at Rust HQ <lilyp>except that go is pretty much its own world so you can ignore it for most desktop use cases <lilyp>not sure how up to date our go packages are tbh <vhns>Don't Go devs even use a tool that allows you to have no operating system at all? <vhns>Like, it just straigh up is an image of your application on boot and that's it <lilyp>yeah, they statically link a lot, probably more than appimages even <luke-jr>vhns: I expect it probably still uses Linux under the hood <vhns>I can't recall the talk I watched <vhns>I wish I could link the talk, it was about Router 7 in gophercon 2018, but it's only available through YouTube <vhns>Yeah, it's for bare-metal <the_tubular>the gokrazy system (minimal init system, updater, DHCP, NTP, …) <lilyp>exactly what it says on the tin <avalos>Hi, people! I have two questions about Guix, as I'm planning to install it on my laptop soon. <avalos>1. Does Guix support secure boot installation? <avalos>2. What's the learning curve if I'm coming from Parabola? <avalos>By Guix supporting secure boot, what I mean is, the default installer facilitating the creation of a secure boot installation. <avalos>Bonus question: is Guix an immutable system? <avalos>I had the feeling that someone would tell me that. :P <avalos>Without going too much into semantics, what I mean by "immutable" is more or less that the base system files are protected from modification from user processes. <avalos>Similar to what distros like Fedora Silverblue do. <zeropoint>I can no longer reconfigure my system... guix pull seems to work fine, but reconfiguring errors out... Anyone else had problems recently? <zeropoint>hmm can I force guix to rebuild it's git cache? <wonko-the-sane>gnu/system/file-systems.scm has an opinion that excludes 'discard' from the set of valid mount flags, this is surely a bug right? <dcunit3d>if i want to learn to write Guix packages with Rust deps, like where do I start? <dcunit3d>it's a crate with wayland and graphics deps. it has four crates. i plotted out the deps using `cargo depgraph`. <dcunit3d>but i don't necessarily need to do that first. i'm more interested in figuring out what i should look at if i was to "triage" a rust application <mbakke>dcunit3d: a good place to start is 'guix import crate -r the-crate' <dcunit3d>i don't have high hopes for this package, but i would like to generally learn how to do it <lilyp>dcunit3d: if you can't just recursively pull in the crate, then you're in trouble; it means you have to parse the toml file yourself and figure out what goes where <nckx>wonko-the-sane: No, why? <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>Because there's a ‘guix’ to ‘describe’. <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>nckx: It is using `fold-packages' <nckx>OK, so emacs-guix is *not* invoking it on something like /home/pastor/.guix-profile? Because that's what I thought you meant. <nckx>Not your fault, maybe my fault, text is hard. <pastor>Internally is using `fold-package' which uses `all-modules' in one of the optional arguments <pastor>This `all-modules' receives an argument which is this function call `(%package-module-path)' <pastor>which tries to expand %load-path with user channels <pastor>To get those user channels it uses this function call `(package-path-entries)' <pastor>Which relies on this other call `(current-channel-entries)' <nckx>ACTION wonders why ‘guile -L ~/guix’ → ,use (guix describe) tries to rebuild all of Guix, but can't be arsed to find out. <pastor>which calls `(current-profile-entries)' <pastor>This is already the last call which should provide all the profile info and the channels that built the profile <pastor>It has this docstring: Return the list of entries in the 'guix pull' profile the calling process <pastor>lives in, or the empty list if this is not applicable. <janneke>nckx: if i'm guessing that your ~/guix is my ~/src/guix/master, then try something like <janneke>guile -L ~/src/guix/master -C ~/src/guix/master -- ,use (guix describe) <nckx>Worked, thanks. So ~/guix uses its own cache? <janneke>Eh, -L sets _only_ %load-path (no idea why, guile bug/feature?), -C sets %load-compiled path <janneke>i guess you just have compiled .go files under ~/guix <nckx>pastor: Did you look at the code? Because it's pretty naive, if that's the right word (or at least it doesn't anticipate non-Guix-command usage like emacs-guix is attempting). <janneke>not sure if you would want to call that 'cache' <nckx>So emacs-guix should shell out to ‘guix’ to make this work, or the code needs to be made More Clever (uh oh) <pastor>So the problem is that invoking `guix repl` and doing the -- ,use (guix describe) <pastor>(current-profile-entries) works good. <pastor>But if you do `guile' repl -- ,use (guix describe) <pastor>(current-profile-entries) it does not work. Yields an empty list <nckx>Right, because it string matches on "guix", literally. <nckx>…/bin/guix even, my bad. <janneke>but in these cases (pointing to a working tree), i think it's weird to have to set _two_ paths for guile <nckx>janneke: Right, I just meant that the invocation without -C spams me with /home/nckx/.cache/guile/ccache notes. <pastor>nckx: What code you suggest reading? <nckx>It didn't seem to be very cachy but I didn't give it a chance to finish, because it takes a very long time. <janneke>let's nudge our guile liason(s) about this <pastor>nckx: ups. I'm reading now tha part where it string matches 'guix' <pastor>I don't understand the reasoning for this... <pastor>Ah no. This is to remove the default guix channel <pastor>Yeah. But thats for `current-channel-entries' <pastor>It tries to get the extra channels so it seems fine that it removes the default `guix` channel <pastor>`current-profile-entries' already is behaving differently on a guile repl and in a guix repl <nckx>Why's that unexpected? I'm missing something. <nckx>Why would it return something under guile? <pastor>It's unexpected for me since emacs-guix is running on a guile repl <pastor>The internal repl that `emacs-guix' is using is not capable of geting the extra channels <pastor>If you have `emacs-guix' availeable you can enter the reple with the command `M-x guix-switch-to-repl` <nckx>I'm just saying that looks expected to me based on the current code, not that the top-level behaviour shouldn't be fixed. <nckx>I can have it available in a minute or so, after it starts up, but I've noticed the missing user channels before. <nckx>ACTION away to look at solar panels. <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>ACTION the panels are still there, good. <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? <nckx>Yes, I pointed that out earlier. <pastor>Yeah. I missed your point, my bad. <nckx>It's still not clear to me why this implementation would be broken. <pastor>But as I see it, most of the functionality we need is provided by the 'guix describe' module. What interface should we use instead? I don't think we have any <nckx>More succinctly: can you explain why (guix describe) is broken, as opposed to emacs-guix? <lilyp>I think it's the opposite – emacs-guix can't find our guix describe, no? <pastor>No no. I believe that `emacs-guix' is the problem here. But I don't see how it could be fixed without guix providing an appropiate API for this <lilyp>But isn't guix describe the appropriate API? <nckx>Since I can't get emacs-guix to launch because it's a Sunday, I can't do my favourite bang-on-things-until-they-spill-their-secrets debugging technique. <lilyp>You can call our commands and their innards from a REPL <pastor>lilyp: I think `guix describe' could be the appropiate API if it allowed to be used on repls which do not have the name `guix` on it <nckx>F this, I'm going to remove the string-suffix? test and see what breaks. <nckx>Rather than divine authorial intent. <nckx>I've been burnt by outdated docstrings twice this week; no longer. <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>Not sure If I'm doing it correctly. I get this: <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 <potato_lisper> Git error: object not found - no match for id (e134686cead6db62ea8b941b2ed7c0bd660804da) <lilyp>potato_lisper: sudo rm -rf /root/.cache/guix <pastor>lilyp: the later is the correct one <pastor>lilyp: Oi oi. I think I see a problem. Check out the `guix-external.el` module of `emacs-guix` <pastor>The definition of `guix-guile-program` <pastor>It relies on `guix-config-guile-program' <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. <lilyp>"Will close bug" – yes, because you're deleting the package. Any reason to do so upstream-wise? <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 <mirai>transfig (the package name) was renamed to fig2dev (the package name) <mirai>I asked about marking transfig as deprecated but there's no dependent packages in guix <mirai>and the feedback I got was: no need <mirai>s/the package name/the project name/ <lilyp>did you ask all the guix users? <lilyp>(exaggerated, but you get the point) <mirai>yeah I understand the point and went to inquire about it <lilyp>that's for a different deprecation mechanism <lilyp>we also have (deprecated-package …) which is more appropriate here <mirai>your 3-commit plan sounds good to me <mirai>lilyp: (define-public transfig (deprecated-package "transfig" fig2dev)) right? <mirai>ACTION used git grep for a quick answer <lilyp>Looks right to me, but I always mess up the order myself てへぺろ☆(・ω<) <potato_lisper>has anyone have some tutorial how to setup Distrobox? Currently getting error "Error: could not find a supported package manager. <lilyp>from the packaged distrobox? <lilyp>if so, that looks like a bug to me <nckx>mirai: My feedback was not about deprecated-package, but some other deprecation type you were asking about, that's all I remember. <mirai>nckx: yeah, I wasn't aware that they meant diferent things <nckx>No problemo, it is confusing. <nckx>One's for in-tree users, of which there are none, this is for folks who've installed it into profiles. It is indeed polite to redirect them like you do. <mirai>I wonder, is it worth doing a “merge 63153 65873” control message? <mirai>There are cases where the bug report and the patch are filed separately <lilyp>I can only recommend merging bugs – makes them easier to close :) <lilyp>patches are applied locally, will upstream next sunday <podiki>just did a pull and in trying to reconfigure get a "Git error: object not found - no match for id (e134686cead6db62ea8b941b2ed7c0bd660804da)" haven't seen this before, what does it mean? <podiki>(my guess would be to clear something in ~/.cache but haven't tried) <podiki>same error after clearing ~/.cache/gui* <lilyp>podiki: you need to clear root's cache, not your own <podiki>lilyp: thanks, that worked! any idea how this happens? i only ever use sudo for system reconfigure, never anything else <lilyp>sadly no more than a hypothesis <podiki>can't say i've ever seen it before <podiki>also i'm confused, but i guess running sudo guix while using the user's environment uses root's cache? <podiki>bumble: just hit the same thing here <bumble>if anyone has advice, please share and I'll try it out <bumble>I did do that and it didn't change anything <podiki>and your user's cache too? (maybe .cache/guile for good measure too) <lilyp>It's getting stranger and stranger by the minute <podiki>maybe certain commits or series of commits....something something cache? except not the same fix it seems <bumble>yes I I deleted all of ~/.cache yesterday <bumble>but today only tried deleting ~/.cache/guix <bumble>the id seen in the error did change from yesterday though that is probably not important <podiki>and you made sure you actually deleted root's cache? <podiki>the id is the commit of guix you are at <podiki>e.g. sudo rm -rf ~/.cache/guix will remove your user's directory, not roots, use /root explicitly <bumble>doing guix pull and my connection is a little slow so might take some time to know the result <podiki>or maybe should save the old cache directory for debugging's sake....i deleted mine already though :( <podiki>in my case guix pull was fine but sudo guix system reconfigure hit that error <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 <podiki>but some sort of caching issue....? <lilyp>I still think it's because of the merge commits <podiki>if you have the bad cache then maybe we can see what is wrong with that checkout? <podiki>lilyp: that was my guess, but something specifically huh? since we don't have huge reports of it when we do other big merges, wonder what the common factor could be <lilyp>Don't know about glv, but I'm a complete amateur when it comes to merging big branches. <jackhill>ok, I'll uplodad it someone (if it's small enough, I can put it in the bug tracker). Is there an exisitng issue? <lilyp>staging and core-updates at the very least were always coordinated by folks who knew exactly what they did <lilyp>jackhill: the weird thing is we already use libgit2 to update the checkout before that <podiki>is cuirass doing gc or something? I tried to restart some builds from the web interface but there's nothing building <podiki>(i see failures after the merges but succeeding locally) <bumble>podiki: system reconfigure completed succesfully <bumble>well thanks everyone I'm headed afk <euouae>I don't understand the sequence `guix pull; sudo guix system reconfigure` <euouae>In particular, what does guix system reconfigure do? <euouae>I thought guix pull takes effect anyway, isn't a new generation listed with guix pull --list-generations? <euouae>(I do realize system reconfigure installs a new kernel, I can tell that much) <bumble>guix pull updates the guix system itself, guix system reconfigure applies the system definition to the host eg it updates your computer system <euouae>so they're actually separate, right? <euouae>It's not so clear from "After System Installation" in info pages <bumble>and theere is also guix home reconfigure, which applies the home definition to the host <lilyp>guix pull only updates your package definitions <euouae>YEah, system reconfigure actually installs system packages, right? <lilyp>exactly, plus the bootloader and stuff <euouae>guix pull also updates versions of installed packages immediately though right? <euouae>such as guix itself, or e.g. emacs <bumble>sytem reconfigure installs whatever packages are needed to satisfy the system configuration definition <euouae>e.g. emacs --version and guix pull && emacs --version are different <lilyp>nope, it just updates the guix channels (including the guix command) <euouae>oh right, you need guix upgrade for that, right? <lilyp>emacs --version stays the same unless your emacs is an alias for `guix shell emacs -- command emacs' <euouae>guix pull && hash guix && guix upgrade is what I have in my notes <lilyp>hash guix is only needed after logging in for the first time <bumble>I only used hash guix and guix upgrade when I first set things up <lilyp>because the guix switches from /run/current-system/… to /home <lilyp>guix upgrade without any installed packages is a no-op <lilyp>or do you just push everything into config.scm <euouae>I started with bare-bones.cfg and I installed some packages with guix package -i <euouae>That's how far I've experimented with Guix thusfar <euouae>I'm still lost on the previous question <euouae>I don't understand, does guix upgrade actually upgrade my current packages or not? <euouae>e.g. what's the debian equivalent of apt update && apt upgrade (assuming no system reconfigure though) <bumble>euouae: guix upgrade updates packages that were installed with `guix install` <lilyp>if you just run guix package -i and no guix package -u (note you can do both on the same line) you will have outdated packages <lilyp>guix install and guix upgrade are aliases for the above with friendlier names <bumble>if, for example, you use guix home, home-installed packages are different from regular guix-installed packages <euouae>So as I gathered, some users like to have all their installed packages in /etc/config.scm? So they only system reconfigure? <euouae>bumble: is guix home a newer approach? <euouae>I haven't actually seen it in the manual yet. <lilyp>it's been in technological preview for a while <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 <euouae>(use-modules* (gnu (home (() services (desktop gnupg guix pm shells))))) <euouae>bumble: how is guix home different from guix profiles? <bumble>I'm still kind of novice and don't want to give wrong information so can't really speak to profiles <bumble>euouae when you say "profile" is that a system config file you are referring to? <euouae>No, the profiles under `guix package --list-profiles` <euouae>You can create your own and switch to them. I think guix home might be a wrapper around it <euouae>because the way you describe it is a bit like how guix profiles work <bumble>oh _think_ those are various states of things associated with vanilla guix install and guix upgrade <bumble>guix home let's you manage your home-things like dot files and bash aliases etc separately from your system configuration <euouae>Are you using guix system or guix on top of a distro? <euouae>Okay can you explain a bit about the following: suppose I install the bare-bones.cfg system. Now I want to install emacs. How would you do it? <bumble>I would recommend using guix home yes <euouae>It includes Emacs, and then you run which command? <bumble>add emacs as a package to the home definition <bumble>then apply the home definition like `guix home reconfigure myhomefile.scm` <euouae>ah it's similar to system reconfigure <euouae>and where do you store these home .scm files? <bumble>euouae: yes its the same sort of pattern like a system config but using different expressions to define a home configuration rather than a system one <euouae>Do you have multiple home files? <bumble>usually people store them in one place like system.scm, home.scm and maybe channels.scm if you like to have those in separate file <bumble>most people have multiple home files but I only use one <bumble>well not sure what most people do actually <bumble>I think most people have multiple system.cfg files for different architectures <euouae>well sometimes I may want special environments to hack stuff <bumble>and then apply the same home file to all of those <euouae>for example I may want "X" application and "Y" library dependency but personally modified. Is it appropriate to use guix home for this? <bumble>yeah there are lots of ways to setup special environments in guix from what I have seen <euouae>so you store the home scm files under ~/ right? <bumble>I have mine stored inside of a cloned git repo at ~/software/guix-home <euouae>Makes sense. I don't use git for personal files, I prefer backups <euouae>But thanks for all the help! I appreciate it <bumble>and basically I do this `cd software/guix-home && guix pull && guix home reconfigure guix.home.scm` <euouae>Do you not bother upgrading the kernel? <bumble>git is nice if you have multiple machine because you can share changes among machines in seconds with git pull <euouae>Hm... you're right. Maybe home .scm files should be in a git repo <bumble>I update the kernel less frequently <bumble>euouae cool I hope I helped it is fun to write about it here <bumble>you will really like it if you install and set it up <euouae>I'm trying to figure out some stuff still <bumble>the system I'm typing from started with a barebones sort of configuration using the nonfree kernel and I gradually added and changed things so that a home config is now used <euouae>Or I might give up and go for gnome or xfce, who knows <bumble>I think, if you get a guix system working... you will never go back to using arch or gentoo or ubuntu or whatever <euouae>Guix does seem a more experts distro though... I might not be able to stand on my own without the millions of stackexchange/mailing list posts to hel pme <bumble>things are way more stable and if you migrate to a new machine, you can apply your home config there and instantly have everything setup the optimal way you like <bumble>also after using basic parts things are routine and no need to be an "expert" I'm a novice <bumble>but the initial setup w/ nonfree kernel was very challenging <euouae>I sometimes do stuff that's a bit outlier on what a typical user does <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 <avalos>lilyp: you say `guix home` is in technological preview. Is it possible to start using it with the latest Guix release, or do I need a beta version, or something? <Altadil>avalos: you can already use it with the normal Guix :) <Altadil>I think preview means you may still run into bugs <Altadil>And also the way it works may change <euouae>Various software prefer to manage themselves <euouae>what happens to these under guix? <euouae>For example, python's pip can install system stuff, nodejs, etc <euouae>wow guix gc deleted over 2GB of stuff <euouae>I didnt' realize it woudl delete all the derivations, I thought it'd delete only installed packages that are not necessary <lilyp>euouae: they get very annoyed by missing write privileges <euouae>lilyp: hahah is that what happens? <mfg>Has anyone tried to use or package AdaptiveCpp (formerly hipSYCL, respectively OpenSYCL) on guix system? <lilyp>yep, they're writing warning messages in all colors, though mostly red, black and white <lilyp>mfg: looks like you'd need to cut out a big fat cuda block to make it worth packaging <lilyp>reminds me, there's still some stuff on the queue from miking <lechner>Hi, is someone looking into the Data Service? packages.g.g.o can't connect <euouae>it might not be guix' problem lechner <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>hm, i see. I'll have to look more closely at the code then to know whether i'd have to remove things or not :) <jaeme>What is the rule when an older version of a package doesn't have a license but its newer version does? <jaeme>I ran into a rust crate with (license #f) <jaeme>Should I keep it that way or copy the newer version's license <jaeme>It doesn't even have a homepage to a git repo or anything <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 <euouae>guix shell syncthing runs a shell <euouae>guix shell foo -- foo runs foo after creating the environment; guix shell foo runs a shell by default <lechner>euouae / Hi, how do you use downdetector for packages.g.g.o, please? <euouae>lechner, I did not; I noticed another user here, bean123, complained about <ci.guix.gnu.org>, and I also noticed that downdetector mentions various websites being down <jpoiret>mfg: crucially, with `--` guix shell does not spawn a shell <euouae>On a second read the guix manual is a lot more understandable now <mfg> jpoiret, euouae: thanks, that make sense <SusanTheNerd>I keep getting an error of device not found. I tried to define the filesystem device using uuid, the label method or by /dev/mapper/vg-root(I use different names than in the guide <euouae>so the issue is after reboot, right? <euouae>from a glance at that manual it's a standard LVM & luks installation with a specific config.scm file for guix <euouae>Do you know how to install LVM & luks on other linux distros? <SusanTheNerd>I even tried it with luks1 and luks2 and couldn't get it to work <euouae>Give that a try, it will help to know which part of your configuration is not working right <euouae>Because if that works, you can then add another encrypted volume and see if you can get _that_ working <SusanTheNerd>I even found someone with the same problem on reddit and they fixed by using luks1 but that didn't work for me <euouae>SusanTheNerd: do without luks for now <euouae>GRUB has limited support for luks2, and luks1 is used for partitions GRUB must unlock <euouae>you should use luks2, why do you want full-disk encryption? <euouae>SusanTheNerd: are you doing this in a real install or a VM? <SusanTheNerd>I wish fade because I keep sensitive data like my browser history on it <euouae>SusanTheNerd: full-disk encryption is for people who want to encrypt /boot, the kernel image <euouae>the kernel won't store browser history (hopefully not!) <euouae>I'm only asking because FDE is a lot more complicated but you don't get much out of it <euouae>if you just want to secure important data, you can encrypt everything except boot <nckx>Is that true for Guix System tho? <nckx>The convenience argument, I mean. <nckx>Legendary pain, but maybe that's changed. <euouae>Oops. Okay, then just encrypt home... <nckx>While FDE works by default as long as you don't mind entering your passphrase twice. <euouae>but there may be leaks by software that writes sensitive data elsewhere. That's definitely not as nice as having everything encrypted <nckx>What do you use to encrypt /home on Guix System? <nckx>ecyptfs? Or is that old news. <euouae>I haven't attempted any of this yet on Guix <euouae>yeah I was giving bad advice again <nckx>A word of caution: beware of recommending things as 'easy' or 'hard' based on other distroes. <nckx>Guix is 'special', for better or worse. <euouae>ACTION oO ( The finger-crossing promise equivalent on IRC is to make a well-calculated typo in a sentence. ) <nckx>ACTION loses their nerd cred. <nckx>As a special concession to our teenaged users, Libera should be 8-bit clean. <avalos>I just ran the installation process for Guix, RIP my 2 year old system. <avalos>Now I hope I can easily install KDE. <nckx>There's ehm... there's plasma-desktop-service-type. <nckx>Boy do I hope it actually works or you'll be disappointed. <avalos>But I'm not sure what's its current state. <nckx>avalos: It's the name of the service type argument you'd add to your system configuration, assuming you're running Guix System. <nckx>avalos: Very, very new AFAIK. <nckx>No, but Guix is rolling release, you're not expected to run 1.4.0 but to 'guix pull' to master. <avalos>So, 1.4.0 is more like the installer?