IRC channel logs
2024-11-25.log
back to list of logs
<noe>Hello IRC! I am starting to make a new revision of the “RFC process“ patch. I think it would be a good first step for the future of Guix, unlocking the way for governance and collaboration changes and big refactors. Since I am the first one to ask for changes, I thought I would try my best to move things forward :) I will need a co-supporter (preferably with commit access) as the first version recommends, anyone <viferga>Hello, I am trying to build NodeJS package for i386 but some tests seem to work, I have tried to modify the package, even delete the test phase completely but I got no luck, any th <viferga>Hello, I am trying to build NodeJS package for i386 but some tests seem to work, I have tried to modify the package, even delete the test phase completely but I got no luck, can you help me on this? <viferga>This is what I did, I tried also to delete the tests that fail but no luck neither... <viferga>I mean some tests don't pass, sorry. <stochastic>Can you add an environment variable ad-hoc to a shepherd service? <unmush>hey question, when adding a bootstrap path for a language, does guix want it in a few patches or the usual one-commit-per-package? <unmush>I've finally got mono up to 6.12.0.206, and it looks like it's going to come out to over 20 packages in total <podiki>stochastic: there is #:environment-variables keyword in make-forkexec-constructor (when you define the start of a service) <stochastic>> stochastic: there is #:environment-variables keyword in make-forkexec-constructor (when you define the start of a service) <stochastic>I was thinking about adding a variable to an existing serivce <podiki>i suppose you could extend it in some way then. not sure the easiest <wakyct>I'm looking into writing a package for an app that uses Juce, which doesn't have a package (there is an open patch currently to add it). I noticed there's another package that already does use Juce because the source repo vendored it in <wakyct>the app brings in Juce as a submodule. Should I package Juce separately here? <podiki>yes, generally we try to unvendor <podiki>sometimes things are missed or take time to unvendor everything <wakyct>thanks, I'm noticing for juce in particular it seems quite common to vendor <wakyct>I guess part of the answer here is to help review patches to get them closed ;) <podiki>some things may not make sense to package on their own, though we still do sometimes (like source only libraries) <stochastic>guix makes it very easy to unvendor compared to other package managers too <reyman>I look one more time to package protonbridge into guix because i missed my mail on emacs ... jpoiret you say you have tried, i'm interested to look at your experiment if you have one :) I already package rust, but go is a new thing for me <jaadu>It seems that home-dotfiles-configuration will walk the directories and create symlinks for each file it finds rather than create symlinks to the directories it find. How unfortunate. <jaadu>Am I understanding it correctly? <bdju>is ntpd broken for anyone else? <bdju>or really what I want to know is how to fix it I guess <bdju>my clock is drifting and I see the service is stopped and it fails to start when I try <bdju>I think I saw something about this on the mailing list earlier but I didn't read it all at the time <bdju>I'm pretty sure I lost an eBay auction earlier because of this time mismatch actually. I assumed it was the website that was broken at the time <efraim>I restart ntpd when I remember to <bdju>never had a desync on guix system that I can recall prior to now/recently and I can't start it at all <bdju>in the process of upgrades in case it fixes anything but that's a slow process <civodul>for me ntpd is always started but i’m under the impression that it doesn’t do its job <bdju>and I made the mistake of doing my user packages first when ntpd is probably a system thing <civodul>i’ve seen machines that were drifting <futurile>jaadu: you can use one of the services to create a link to your existing dotfiles if you have those - I'm assuming that's what you mean by creating a link to a directory <rekado>bdju: I use (allow-large-adjustment? #t) in my ntp service <bdju>well the service wasn't running at all and is failing to start, I don't think that will help me <rekado>I needed that for machines that have an unreliable clock <rekado>bdju: it won't do anything if it has drifted too much; that may be the reason for not starting <rekado>run ntp manually with arguments to allow large adjustments <bdju>I know that it can't do large adjustments, I am aware of that limitation. in which case restarting it or rebooting should let it correct anyway, or you can manually set it closer with the date command and then it should correct shortly <bdju>but in all those cases I believe the service should still start/run even if the time is not then fixed <bdju>wait, does a service have to be enabled to be started? does enable in herd mean something different than in systemd? <bdju>the only thing in the log I see is that it's currently disabled <civodul>what about “kernel reports TIME_ERROR: 0x41: Clock Unsynchronized”? <Rutherther>bdju enabling in shepherd is not the same as in systemd. All services in shepherd start as enabled, and they get disabled automatically in case of respawning too much. Enable in systemd means to put a symlink to its target folder, but thats not a thing with shepherd. <civodul>i think this was discussed some time ago but i forgot what the conclusion was <bdju>I see that on the 10th ntpd was segfaulting repeatedly, and my uptime is 14 days so it must've been an issue last time I rebooted (there's always something) <bdju>then it probably sank behind a second a day or so and I only just noticed <bdju>I do not have a Clock Unsychronized message that I see <bdju>so I don't know the cause or if this will happen again but for the time being my clock is working <futurile>Q: (list-matches "(^bumpalo.{,4})(>= 3.11, < 3.15)" "bumpalo = \">= 3.11, < 3.15\""), it shows it's matching the 2 subexpressions, but I can't figure out how to access the second one (e.g. I'm trying to get the second part of the line) <futurile>the list-matches shows $316 = (#("bumpalo = \">= 3.11, < 3.15\"" (0 . 26) (0 . 11) (11 . 26))) - so that seems totally correct, it's matching the full thing, and the two separate subexpressions get the two parts <futurile>gah it's (match:substring (string-match "(^bumpalo.{,4})(>= 3.11, < 3.15)" base-str) 2) - to get the second part <futurile>ACTION goes off to read more on Scheme's gexp <dcunit3d>does anyone use emacs-arei and guile-arel-rs for guix development? <rekado>janneke: I'm very happy to read your blog post. Magnificent work, as always! <janneke>rekado: thanks, that's so good to hear! <janneke>ACTION is pretty happy too with all the progress <attila_lendvai>although, much of the great features of Slime resides in its backend, Swank as CL code. e.g. the fuzzy completion code, which wouldn't be usable without rewriting it for guile (or rewriting it in a way that could compile both in guile and in CL). <bost>Hi, `guix pull` reported "aborting update of channel 'guix-past' to commit f99ada4123de1eadf668d34dac2d726407634549, which is not a descendant of 5fb77cce01f21a03b8f5a9c873067691cf09d057" <bost>I was like "maybe I don't need it in the first place". I tried `guix pull --no-channel-files` and then `guix pull --channels=$HOME/.con <bost>and then `guix pull --channels=$HOME/.config/guix/channels.scm` where the $HOME/.config/guix/channels.scm doesn't contain guix-past <Rutherther>bost: so what are the channels in the repo? are you sure none of them have guix-past as dependency? <bost>Rutherther: aaaah! channel dependencies... thank you. Yes I'm pulling it via dependencies. :facepalm: <futurile>attila_lendvai: guile-arel-rs is using the nrepl protocol (https://nrepl.org/nrepl/index.html). I guess the main benefit is it makes the REPL interruptable. nrepl is popular in the clojure world and in some others. I'm interested in guile-arei-rs for Vim, but atm there's no implementation. <futurile>I'm trying to encourage the Conjure plugin author to do one for Scheme heh, but no luck so far <attila_lendvai>futurile, when i use Slime in CL i can interrupt the repl, and i can have multiple repl connections to the same backend. maybe it's the implementation? maybe swank CL uses threads, while guile-arel-rs is not a threaded API? <acidbong>can guix (the distro) create virtual machines with given configs akin to `nixos-rebuild build-vm` and `nixos-shell`? <sneek>acidbong, you have 1 message! <sneek>acidbong, janneke says: i haven't seen a system-config generation tool outside of the installer, that might be neat to have <acidbong>(dang, i don't have chat history to look up the context) <Rutherther>acidbong: guix has commands "guix system container" for containers and "guix system vm" for vms. These build guix system, and run it in a container/vm. You don't have to be using guix system to use it. Just guix on any distro is fine <attila_lendvai>acidbong, there's `guix system image` and `guix shell --container` <Rutherther>attila_lendvai: guix shell --container is something else though. It is a shell that will be started in a container. nixos-shell is for making nixos system (that means really a full fledged system with all its services, ...), and launch a shell inside of it. <attila_lendvai>Rutherther, oh, good to know, thanks! actually, i'm looking for a better setup than `guix system --no-graphic vm ...` where all i get is a dumb serial console to the spawn VM. i'd appreciate ideas if you happen to know a way to have a smarter shell connection than the virtual serial port. <janneke>acidbong: hehe, meanwhile, the installer can be run in dry-run mode, directly from guix's source tree, which will in fact create a config <janneke>ACTION has forgotten the context too, so this may or may not be of any interest to you <janneke>acidbong: yeah, however i meant mothacehe's suggestion of the `guix system installer' command in this context <x8dcc>Hello, I am still confused by the guix environment variables. I sometimes get this message when installing or removing packages, but I have set this exact lines in my '.bash_profile': https://bpa.st/FL7Q <futurile>x8dcc: I think it probably tells you that anytime you install something where there's a new environment variable being added that needs to be sourced. For example, say you didn't normally have Python installed, if you added it then there are GUIX_PYTHON_ environment variables, those need to be sourced in your current session. You can probably try it out in a `guix shell` to see what it's adding. <User-42>I would like to setup a guest user on a VT in my computer setup. At the moment i'm not running any system-wide services for xorg or similar, but simply running "sway" in a login shell. I've been trying to find something more user-friendly that can be run the same way, ideally wayland, but xorg is ok if i don't have to run it globally. Any pointers? <x8dcc>futurile: I see. I was confused because I thought it could be related to the bash-completion issue I mentioned yesterday. I don't understand why it would work on TTYs but not on PTS <futurile>x8dcc: maybe it is. So it's not happening right "after" you install something? It's related to when you use a tty or a pts you think? <futurile>User-42: you could give the user a login and then they run startx (or whatever) like you do, OR you have to run a greeter. There's lighter weight ones than GDM. <x8dcc>No, no, I think I wasn't clear. My real problem is that bash-completion does not work on terminal emulators, but it does work on TTYs. I still haven't fixed that issue. I though it could be because I didn't set some guix env variable, and I thought those messages after installing packages could be related. <x8dcc>However, I think you are right, and those hints just indicate that the package update (could have) changed something <User-42>yes i'm planning on just giving a login, i do not want to run any system-wide greeter <x8dcc>Besides, I tried comparing the output of the 'env' command in the PTS and TTY, and they are almost identical (apart from usual DISPLAY stuff) <User-42>however guix seems set up to only use system wide desktop services for things like gnome <User-42>sway seems like an outlier in that it's possible to just have the package in a home profile and run the executable <futurile>x8dcc: they should be the same, one way to check would be to manually 'source .bashrc' etc from each one - then you know each one has done the same thing. <futurile>User-42: I guess you'd have to set-up the user, in the system config, and then install the packages at a system level that they can use. Never done a true 'multi-user' system. <futurile>x8dcc: and yet you don't get bash completions, do you have to tell it to run /etc/bash_profile?? (or whatever it's called) to get them <futurile>x8dcc: what happens if you run that in a virtual terminal? manually I mean <x8dcc>Sorry, but run what, exactly? <futurile>that was duh to myself for accidently mentioning the other person and not you x8dcc - just to be clear! <futurile>hah - so does it work if you do it manually? Cos I guess that tells us that the test is the problem <x8dcc>Copy pasting those 5 lines (39-43) into the PTS didn't change anything. It shouldn't, since those files don't exist on those paths <x8dcc>The strange part is that it works on the TTYs <futurile>and it works if you just plain: . /usr/share/bash-completion/bash_completion (from a virtual terminal) <x8dcc>bash: /usr/share/bash-completion/bash_completion: No such file or directory <x8dcc>(there is no bash-completion file on /etc, either) <futurile>there's a bash-completions package right? where does it put its stuff <x8dcc>Which is used when installing bash-completion <x8dcc>futurile: Hahaha, what a coincidence <x8dcc>That link answers your question <futurile>OK, so you should get a run/current-system/profile/share/bash-completion/completions if you install it at a system level I guess, or at least you get a profile version if you install it as a user <futurile>so can you source one of those manually? <x8dcc>It's installed at a system level, and that file does exist. Sourcing it manually does work on the terminal emulator <x8dcc>Still, I have no clue why it worked on TTYs <x8dcc>I also tried removing it from my system config and installing it from 'guix home', but same result <futurile>OK, no clue - you might have to email the help list - see if someone understands it <reedm>Hi Guixers! Is there a spec for the socket-based interface of the Guix daemon? I've read the "Invoking guix-daemon" and "Setting up the Daemon" sections of the manual, but I can't see anywhere what sort of signals the Guix daemon is expecting over its listening socket <gabber>reedm: not sure there is an official one, but i guess it would be pretty much the same as upstream Nix's. i personally try to keep my distance to such low-level endeavors. what exactly are you trying to do/what do you want to achieve? <reedm>gabber: I'm thinking of building a service that manages VMs built in the way "guix system vm" does. Initially, I can scrap things together by just calling the guix commands directly in the program, but it feels like there should be a better way <gabber>what feels wrong? how "in a better way"? <efraim>I wanted to see about interacting directly with it from guix.vim previously but I couldn't find anything either then <reedm>gabber: Since I'm not planning to write the service in Scheme, I'd likely end up just wrapping the shell commands and parsing the text of their outputs. It would be nice to have a more static interface (since I assume there's not promises that the guix commands will always print things in the same way as things change over time) <gabber>two thoughts (i am no expert in any of the issues at hand and have of course no further insight in either your goals nor the possibilities at hand): 1. why *not* write the service in scheme? 2. i think most parts of guix's CLI will *not change* in the foreseeable future, e.g. `guix build foo` will always return a path of the package just built, and i guess the same is true for any of the `guix system (vm|container|image)` commands <gabber>using scheme brings the advantage of a powerful, high-level language that allows you to express your program the way you want, with the additional advantage of a de-facto implementation already existing. <gabber>does mumi take care of base-commits in patch-series? <jlicht>does anyone know how to prevent ^C from killing my guix-home-managed user shepherd on my ssh server? <Rutherther>gabber: I don't think so. As far as I know it applies on your currently checked out commit. Also applies to the qa <jlicht>does anyone know of a (public) guix channel that has a nontrivial number of nodejs packages? I'd like to make sure my updates to node are not breaking anyone's deployments :) <Rutherther>jlicht: could you elaborate on that ^C? where are you doing ^C? <civodul>jlicht: ^C where? Home’s shepherd daemonizes so there’s nowhere you can send Ctrl-C to it <jlicht>I have a system (host; bst) everything set up as I like /w guix home. If boot the machine, but only log in remotely (e.g. ssh jlicht@bst), pressing ^C leads to "Stopping service root" <jlicht>pressing it, on the terminal that is logged in using ssh jlicht@bst, FYI <Rutherther>jlicht: does it also log you out? keep in mind, the shepherd home is going to run only as far as you have at least one active user session. <jlicht>it doesn't seem to happen if "on-first-login" is running on a local tty, fwiw <anemofilia>jlicht: iirc aemogie was with the same issue some days ago, I think he solved it, I'll see if I find it <jlicht>Rutherther: It does not log me out <gabber>in the middle of a mumi/patch-review session i am rendered unable to `make` guix "doc/local.mk:34: error: required file 'build-aux/mdate-sh' not found". how can my checkout recover? <Kabouik>How do I write in a native-input that I want go >= 1.22? Is >= a correct syntax in Scheme? I only know about @1.xx but that's for a specific version. <Kabouik>I have a package in my private channel that needs go >= 1.22 but it tries to build with 1.21.5 when I just list `go` as a native input. <gabber>Kabouik: i think you *need* to specify a specific version <Kabouik>I see, thank you gabber. Will try that then. <Rutherther>Kabouik: you can't say go >= 1.22, that's not how guix works. You need to reference a specific symbol that has given version, and it might change in future <graywolf>civodul: I do not think it daemonizes the right way. I can defininetly reproduce. Just log into tty and once you see a prompt press ^C. You will see messages indicating shepherd is stopping. <Rutherther>Kabouik: if there are multiple versions, there is usually one "main" one used the most often, and other ones are named like "package-X.Y", go has the same notation, so there is "go-1.23" for example <jlicht>graywolf: thanks for looking into it. It's not a major issue, just that pressing ^C is the ssh-equivalent to vocal disfluencies :-) <gabber>Rutherther: ah, yes, of course (: thanks! <Kabouik>I saw that Rutherther, but wouldn't `go@1.22` work too in a package definition, since the "name" is "go" and the version is "1.22.7" in Guix channel? <Rutherther>Kabouik: and one more thing, if you are using go-build-system for that package, you should not put it to native-inputs, but to arguments as "#:go go-1.23". Though I would be a bit worried that the dependant packages in guix might not compile for newer go version <Rutherther>Kabouik: "go@1.22" is a specification. In guile you don't use specifications, just symbols. If specifications were used, it would probably be very slow, as you need to go through all packages and find the one that matches <Kabouik>Thanks for the clarifications. I'll see if I need to move go to arguments actually. I'm not sure, because the package actually is built with clang, it's one of its deps that requires Go. My understanding of all this is very partial, which is also why the package is just in my private channel for now. <Kabouik>It's certainly not ready for Guix in its current form. <dariqq>I guess this is one downside of having home-shepherd be silent by default <civodul>reedm: it should be mostly valid; you can see a high-level view of the protocol by looking at ‘define-operation’ uses and similar in (guix store) <civodul>‘define-operation’ defines client-side serialization/deserialization of the daemon RPCs <reedm>civodul: Thanks! I'll take a look at the code <graywolf>civodul: When I check the session ID of the home shepherd, it is the same as the shell itself. So it makes sense that it gets the ^C. However I would say most people do not expect that. <civodul>the ‘daemonize’ action should call ‘setsid’ i guess? <GNUtoo>hi, I've a strange issue with guix git authenticate. We're 2 people managing a git repository, and I made the introductory commit and the other person signed and pushed the commit. <GNUtoo>The key of the other person was valid but I put the wrong hash for my key (I needeed to put the subkey hash instead of the master key hash). <GNUtoo>And so we fixed with another commit, still signed by the other person, but then guix git authenticate only works with the second commit (the fix) as introductory commit, and that doesn't look normal. <ieure>GNUtoo, The new commit comes after the bad one in the git history, so the bad commit is still there. You need to rebase to eliminate the bad commit. <GNUtoo>yes, the new commit is the one right after <GNUtoo>We don't necessarily want to fix the problem but we need to understand it at least <GNUtoo>Because it's a GNU project and we can't rewrite the history of the main branch <ieure>Well, your options are: 1. Rebase 2. Destroy the repo and start over 3. Leave it broken forever. <GNUtoo>Maybe but why is it broken in the first place? <ieure>Because you used the wrong hash, like you said? <Rutherther>GNUtoo: the key has to be first introduced, and only then the commits signed with it are valid as far as I know. <GNUtoo>the other person is neox and AFAIK his key is valid <GNUtoo>My key was not but then he signed the commit <GNUtoo>"git show --no-patch bf2b91df54aa71ecbfab891d32000ad2d6af6093 --pretty=%GP" shows E23C26A5DEEEC5FA9CDDD57A57BC26A3687116F6 <GNUtoo>git show bf2b91df54aa71ecbfab891d32000ad2d6af6093 --show-signature also says "gpg: Good signature from "Adrien 'neox' Bourmault [...]" <neox>I checked with git log --show-signature too <GNUtoo>gitk also shows a linear history <neox>This is a descendant, as far as git is concerned <GNUtoo>"guix git: error: commit c85fbae78f398d12d1df1f27b97e39838c4e08e3 is not a descendant of introductory commit bf2b91df54aa71ecbfab891d32000ad2d6af6093" <GNUtoo>The c85[...] is origin/main and HEAD <neox>Strangely, this is an error I already had with guix <graywolf>GNUtoo: guix git: successfully authenticated commit c85fbae78f398d12d1df1f27b97e39838c4e08e3 <graywolf>You might be just hitting a bug in Guix, it's usage of guile-git is not correct <GNUtoo>Thanks a lot, is there a bugreport about it somewhere? <graywolf>Will *try* to find it. I know I send a patch about that years ago and it went no where, so I just carry it in my own tree <GNUtoo>The patch was in Guix I guess (not in Guile) <graywolf>Yeah, will look through the mailing list, sec <unfroq>Hey Guixers! How can I query for substitutes for packages specified in a system configuration? Just yesterday, I had to compile - several versions of ghc - the whole day to hit ctrl+c in the end, because I needed to use my machine... what a waste of power. I'd like to query for substitues, especially for intense to build packages *before* I <unfroq>reconfigure my system. Any suggestions? <GNUtoo>The issue is also that we need the command to work with Guix 1.2 for instance as it's present in some distributions that are still maintained (like PureOS byzantium (10)). <unfroq>Rutherher: Yes, I know the command, but how can I specifically query for a package tree specified by e.g. my-system.scm. <unmush>does guix weather accept derivations? <GNUtoo>So do you think that, beside fixing it upstream, we should do 'guix git authenticate $(rev-parse HEAD) [...]" or use the second commit? <unmush>if so you could 'guix system build --derivations' to get the system derivation, then pass that to guix weather <graywolf>unfroq: You can use -e to specify an expression. So I guess something like `guix weather -e '(operating-system-packages %os)' could work? <unmush>there's a lot more to an operating system than is captured by its packages field <graywolf>I would expect the long build time to be mostly due to packages, not stuff like initrd... <unmush>you say that, and then you find yourself asking "huh, why am I building 20 versions of rust to reconfigure my system?", and then you find out it's because somehow guix-artwork pulls in librsvg or something <GNUtoo>(like if the commit is smaller than 4k, does it always work?) <unfroq>unmush: from the manual, I can not identify a command to use with a derivation. <unmush>that's too bad, we should consider adding support for it if guix weather can't do it currently <graywolf>Sorry it was long time ago and I do not recall exactly. In general it felt just "wonky", and my digging through the source code suggested the 4k limit. (But there *are* bigger commits in guix, so...) <unfroq>unmush: It gets a bit frustrating tbh. I've had this problem more and more over the past months. <unmush>I wonder why the substitutes for ghc aren't available <unmush>you'd think it's not being changed that frequently, right? <unmush>but yeah, it can be a bit annoying to go about using guix for your user, then decide you need to change something about your system configuration, but you've run 'guix pull' in the meantime and now your little configuration tweak is stuck behind between 5 and 50000 seconds of builds <unmush>a good solution would be to keep around the version of guix that you reconfigured it with last time, so that you can do both "config tweak" and "full upgrade" reconfigures <unfroq>unmush: I pin guix to a specific channel, so I can tweak without recompilation madness. But sometimes I'd like to get a fresh guix experience. With lots of hope, I do a reconfigure just to find out that it takes the whole day and in the end... was pointless :D <unmush>the obvious way to do that would be to use /run/current-system/profile/bin/guix, but IIRC because that uses the guix package instead of (current-guix) you end up using an older guix each time <unmush>was it pointless? I mean, unless it's building a true whopper like ungoogled chromium, surely it's made /some/ progress? <Rutherther>unmush: nothing stops you from keeping it. For example, I have a make file that builds my system, from a guix version that's fixed to channels-pinned.scm in my repo. From this channels-pinned.scm, a guix version is produced also by make. <unfroq>unmush: yeah, no totally pointless... right. But it took quite some power consumption and blocked my system for almost a day... So I am happy to build some packages, but how am I supposed to know when it ends? <unfroq>unmush: So, would you say, if I find a way to extract the specific versions of the packages from a system derivation built from my-config.scm and feed it to guix weather somehow (-e), would that be a potential solution to my problem? <unmush>IIRC doesn't guix usually try to give you a list of what will be built and what will be substituted up front? <Rutherther>unmush: yes, and you can even --dry-run so that it just shows you that, and doesn't perform the build <unfroq>Hmm... okay, I could try to learn which packages are very heavy to build (besides the obvious ones like browsers) and check that upfront. But I would prefer a more automated way. <mccd>How do I install git send-email? I tried adding (specification->package+output "git:send-email") to my packages list in my home config but it didn't work <mccd>Rutherther well I manage to run guix home reconfigure config.scm, but the send-email command is not available <Rutherther>mccd: so you get git send-email is not a git command or what? <Rutherther>have you tried sourcing your profile once more / relogging? <mccd>Rutherther ah is that not done automatically in guix? Think I generally don't need to with new packages <Rutherther>mccd: it is not done automatically. If a new search path is added, you need to ensure the env vars are applied yourself. That's just how linux works, you cannot just pop in a new environment <unmush>you usually don't need to re-source in cases where a search path usually points to a single place in a profile and you've already got something there <mccd>all right, I ran source ~/.guix-home/profile/etc/profile but the command is still not found <mccd>Maybe I'm sourcing it wrong <unmush>and I assume 'guix package -p ~/.guix-home/profile -I git' shows the send-email output is indeed in there? <Rutherther>mccd: okay. Do you have git installed via guix home as well? ... though still the search path should be there even if you have only git:send-email installed via guix home, so it shouldn't really matter with git <mccd>git 2.46.0 out /gnu/store/pfd84yjh2s8pa0rw0ndzs580d431fpfb-git-2.46.0 <anemofilia>mccd: ((compose list specification->package+output) "git:send-email") <unmush>ahhh, specification->package+output probably returns multiple values <unmush>(which is different from returning a list, of course) <mccd> git 2.46.0 send-email /gnu/store/gixg06ff2sjc99p1pjghy9psiymn7fxb-git-2.46.0-send-email <mccd>The new result of 'guix package -p ~/.guix-home/profile -I git' <mccd>Though I still don't have send-email available, even though I sourced .guix-home/profile/etc/profile <mccd>Rutherther I don't have git installed in guix home, maybe that's the culprit <mccd>Ah no adding git didn't solve it <mccd>I'll try logging out and in brb <mccd>Logout/login worked! Thanks everyone <mccd>did I source the profile wrong with my command? Is there a specific way you resource it? <unmush>just to be sure, you sourced it from the same shell you tried running 'git send-email' in, right? <unmush>hmm, and you sourced it again after fixing your packages list? <mccd>well I sourced it with the command I send earlier <unmush>so you sourced it twice overall? once with git:out (unknowingly) and once with git:send-email? <mccd> source ~/.guix-home/profile/etc/profile like this <unmush>I use '.' instead of 'source', but I don't think there's a significant difference? <unmush>'.' is just the posix-compliant way <lfam>I noticed that the package I have in $GUIX_PACKAGE_PATH are no longer being found by the Guix UI. Is this expected or a known issue? <Rutherther>lfam: as far as I can tell guix has moved away from guix package path to channels. Not sure if guix package path is already disabled completely, but it's at least deprecated <lfam>Yes, I know it's considered old-school <Rutherther>lfam: I don't know what you are trying to achieve. But if you have a directory with modules, you can just add "-L /path/to/it" to your commands, and it will load all those modules <lfam>But, I checked the environment of the running Guix process and it does include the proper environment variable, and nothing has changed on my end. So I'm wondering if there is a bug filed about this <attila_lendvai>i think GUIX_PACKAGE_PATH has been retired because it was just a redundant duplicate of GUILE_LOAD_PATH (IIUC guix simply scans all available guile modules for toplevel public definitions.) <lfam>Well, all I'm trying to achieve is to keep using the packages I've been using since like 2017 ;) <jlicht>lfam: does `guix describe` still pick it up? <lfam>Yes, `guix describe` shows the special variable and path <lfam>If this functionality is gone, that's okay, I'll adapt <lfam>I'm not sure *where* the compiled objects are <lfam>Okay, I wiped by ~/.cache/guile and now it works! <lfam>Of course, implicit state was the problem ;) <help-with-boot-r>after disk 1 is decrypted, the system tries to open disk 2, who's key lives at disk1, but fails <graywolf>If that is happening during boot, I can tell you right away that Guix does not mount the dick 1. So I am pretty sure it will not be able to locate the key. <graywolf>I do not think there currently is easy way to do what you want. Afaik the best option is to put the encryption key into a cpio archive and load it using (extra-initrd) field of (operating-system) <help-with-boot-r>if I can reconfigure, I can remove disk2 from the game, and just boot normally <help-with-boot-r>I considered removing the disk2 and reconfiguring, but the mounting is weird <help-with-boot-r>IDK if I'm missing something on filesystem behaviour, or if (mount ...) differs from mount(8) <help-with-boot-r>but after (chdir "..") up to root, (scandir ".") and (scandir "/") show different things <help-with-boot-r>so references to the store (/gnu/store/...) are broken, so a symlink doesn't resolve correctly <help-with-boot-r>removing the leading slash fixes that, as the store does live under "gnu/" <graywolf>I have no idea what the cause or solution here is, but (mount ...) is doing syscalls directly, it does not use the `mount' binary at all. Not sure whether that is useful information. <help-with-boot-r>if I can get the "/" to actually be the root, than a manual reconfigure call would eventually work, as I gradually add environment variables required <help-with-boot-r>I've considered editing in-place the system configuration, so that it gets picked up during boot, but i'm not sure <help-with-boot-r>I'm not sure if I could do such delicate action, without breaking symlinks to it that I don't know of <graywolf>I wonder whether trying to chroot into the system from a live usb would not be safer. I guess that would be some guides somewhere about that. <help-with-boot-r>hmm, from a live usb decrypt disk1, chrooot into it and then reconfigure inside disk1 <graywolf>I mean, it would be *really* cool to be able to fix that from the early repl, but I would be way too scared <help-with-boot-r>in fact this isn't my first time breaking the system and having to fix in the early repl <help-with-boot-r>iirc it was removing a broken symlink that the boot tried to access if the name existed <help-with-boot>i was writing: I wonder if using a stub usb drive as disk2 would be enough to fake it to the boot <help-with-boot>i guess all I'd have to do is make the decrypted disk2 show the correct name in /dev/mapper/$name <help-with-boot>tbh, let me first check that the existing system config would work if disk2 was opened correctly at all <x8dcc>Is there any Guix blog post about the design choices for making it more user-oriented? <x8dcc>Or section in the manual, anyway <x8dcc>I mean that the packages are not generally meant to be installed system-wide <x8dcc>... I mean the general design for the guix package manager. The whole '/gnu/store' system, for example. I am looking for information on why this was chosen <help-with-boot>that was kind of inherited from Nix (note *nix, but Nix from nixpkgs and NixOS) <help-with-boot>they had /nix/store/..., and early guix people replaced "nix" with "gnu" <x8dcc>I know, but I am looking for all this explained in an "official" channel <User-42>Hello again! Anyone has experience running plasma without a greeter? I've gotten so far as having a graphical wayland display, but only a black background. Plasmashell falis with "starting invalid corona \"org.kde.plasma.desktop\"" - any pointers? <User-42>i have a working sway setup already, i have looked at these configs before but not specifically for plasma. <Rutherther>are you trying to start plasma xorg or wayland btw? <User-42>i'm running "startplasma-wayland" in a tty directly <User-42>and i get the splash screen loading, and a "working" env, i can start "foot" in the wayland context etc, but plasmashell borks out with the corona thing <x8dcc>I don't remember who I was talking to about using org-mode for the guix config, but I ended up porting mine to Org. <wakyct>are you putting your init.el in the same file x8dcc? <x8dcc>Haha, no. I don't mix emacs and guix <ieure>Because they're two great tastes that taste great together. <x8dcc>I mean, I use Emacs too, I just don't manage my Emacs packages with Guix