IRC channel logs
2025-04-01.log
back to list of logs
<dajole>Is `guix pull` basically an alias for `guix package -p ~/.config/guix/current -u`? <dajole>Even after reading the documentation, I'm a little confused why `guix pull` is a separate command. <podiki>guix pull updates your local guix (the command and package definitions) but does not do anything to your packages or system otherwise <podiki>guix, your profiles, you system...each can have different versions if you so desire <dajole>Just to make sure I understand, so `guix pull` is simply a convenience if all you want to do is update guix, but theoretically this could also be done using guix package? Or perhaps I'm missing your point. <podiki>no, guix pull updates guix (the command itself, the packages it knows about) <podiki>doesn't touch what you have installed or not <podiki>so it gets you the latest package definitions or changes or additions etc, but doesn't change what you have installed; two separate things <podiki>guix package just works on the packages you have installed, doesn't touch "guix" itself <dajole>So `guix pull` is sorta like `apt-get update`? And thank you for your answers. I'm just trying to orient myself and figure out how the different pieces fit together :) <podiki>guix pull is like git pull in a sense, gets you the new code but doesn't do anything with it <podiki>(which is what it does partially under the hood, getting the latest of the guix repo and any other channels you use) <podiki>no worries, guix is pretty different! <podiki>and you don't need sudo for anything but guix system reconfigure <podiki>otherwise just know that guix operations are atomic and you can always roll-back <Rutherther>jas: exactly, you just start it as other user. Depends on what system you're on, on Guix System just don't care about it, Guix System includes the new service. On other systems, see the new .service file, specifically you should add the capability and start it as other user than root. But if you're already using guix, you're going to have a problem with the store being owned by root, you will need to manually 'reown' everything in there <Rutherther>1. are you sure you're using newest guix?, 2. are you sure you're not using the --build-users-group flag? <Rutherther>and thirdly, are you sure you're giving guix-daemon the chown capability? you will need it for stuff like guix pull <eikcaz>Saw the new guix social. Sad to think npm might get baked into more guix setups (via wider adoption of arbitrary docker images), but that direction is probably wise as it avoids playing wack-a-mole: we can focus on packaging the few services that "win out". <Rutherther>first question is if they support unprivileged user namespaces, if not, you will have to use --no-chroot unfortunately <Rutherther>you can of course still pass arguments like substiute urls <meaty>Is there a way to execute a command and use its text output in a build phase? <anemofilia>meaty: Look at `info guile`, search for ice-9 popen <meaty>Is there a way to get the commit of an input package? not the version, the git commit hash <ieure>meaty, Only if its origin URI is a git-reference. <meaty>ieure: how so if that is true? <meaty>Getting the version tag is trivial ofc, but what about the commit hash <ieure>meaty, You have to reach into the package source -> origin uri -> call git-reference? if true -> git-reference-commit on it <ieure>I haven't tried this, but I suspect it would work. <meaty>I'm trying to package the hyprland plugins in a rigorous way <ieure>How does this help with that? <meaty>ieure: Hyprland plugins are normally managed using a userland package manager 'hyprpm', which functions by checking the current commit hash of Hyprland by parsing it's human-format '--version' output (despite being in the same repo as hyprland, they can't add a '--git-commit' option, i guess), then referring to a .toml file in each plugin repo listing what git commit of the plugin should be compiled for a given Hyprland version... <meaty>ieure: I *would* follow the guix tradition of constructing a "matrix" simulation of the build environment hyprpm expects, but hyprpm has many hard-coded file paths and overall seems very brittle. I think (for now) that I can implement the same behavior more rigorously in guix itself <ieure>meaty, The simple solution is: (define %hyprland-commit "whatever") and use that in all the packages, rather than rummaging around in the source. <meaty>ieure: but that would break package transformations, no? <meaty>At that point just set the commit to the one matching the packaged hyprland <meaty>which is what nix does iirc, but it's not "correct". but then again, does it really matter that much? perhaps I am just being overcritical and nobody will really mind a sub-perfect implementation <ieure>Wouldn't transformations break with your setup, too? <ieure>Or are all the plugins dynamically created by a procedure that takes the root package as an argument? <ieure>Otherwise they're going to reference the hyprland package in Guix, and if you transform that to be a newer version... what then? <meaty>ieure: would they? I think if you do, say, `guix build hyprland-cool-plugin --with-input=hyprland=hyprland@0.47.2` the build process would investigate hyprland's source and recover its proper commit hash, no? then that hash can be fed to an after-unpacking 'checkout-right-version phase. or am i missing something? <meaty>ieure: the documented behavior for hyprpm would be to use the latest git version of the plugin if hyprland's commit is newer than anything recorded in the plugin's .toml file <meaty>for Guix, that would the the commit declared in the origin, i guess <ieure>I don't even know what hyprland is... oh, Wayland thinger. alright. <meaty>do you think this is all overkill? <ieure>I have no opinion... depends on how much you want to use it. <ieure>In the case where hyprland-cool-plugin takes hyprland as an input, what's the expected behavior of hyprland-cool-plugin's origin? Should it clone a version of itself matching the hyprland commit? <meaty>ieure: the origin would remain the same. However, a build phase added after unpack would use the .toml file and switch to the right git commit depending on Hyprland's commit <ieure>meaty, That smells a little... unreproducey to me. <ieure>I'm not sure it is, but it kinda smells like it. <meaty>ieure: I share the feeling, but as long as we're cloning the same commit of the plugin and the same commit of hyprland, we should end up building the same commit of the plugin... <meaty>Anyways, I think I'm deciding to go the way of nix on this for now. After poking around its source code, it's clear hyprpm has a long way to go to becoming a usable build tool (and hyprland develops very fast right now), so it wouldn't be unlikely that I re-implement it all just for hyprpm to become usable a few months later. At least, that's what I'm telling myself <meaty>best case scenario, hyprland implements a stable api or at least api versioning system and hyprpm becomes completely unnecessary <podiki>i briefly saw the patches and the above discussion, but agree to do what is easiest now (just set the commits) <podiki>hypr* moves fast and things will change, doesn't seem like they expect/want upstream packaging of plugins <podiki>any cool plugins? haven't looked at them yet but now you got me curious :) <meaty>podiki: I've been using hyprscroller :) I like being able to add new windows easily without disrubing other windows' sizes or layout <podiki>(well other than how upstream uses nix, so that is a model i would say) <podiki>reminds me i had some packages of openrgb plugins i never upstreamed to guix (to do cool things with lights) <csantosb>Hello Guix ! I realized that patches sent to {python,emacs}-xyz get tagged with a team-{python, emacs} <csantosb>This is not the case of patches to fpga module, is there a reason for that ? Am I doing something wrong ? <csantosb>I mean, fpga.scm belongs to the team-electronics. I would expect it to be tagged accordingly. <FrenchNewbie>can we declare in the config.scm how we want our cursor to look like ? <dcunit3d>when doing `guix build --keep-failed` is there a good way to get reopen the environment used to build the package? i have a golang build that's failing, but i'm not sure why. i've tried --debug=4 and verbose output. <FrenchNewbie>i got a bibata .tar.gz archive i'd like to use as reference, not a package <Rutherther>dcunit3d: probably the best you can do is, being in the /tmp/...build... folder, 1. guix shell -D the-package --container, 2. source environment-variables <FrenchNewbie>on guix pull or reconfigure i get the error "can't connect to « /var/guix/daemon-socket/socket » : Connexion refused" <xelxebar>FrenchNewbie: Does pgrep guix-daemon show a running process? <xelxebar>So it's running and guix-daemon isn't doing anything. In that case, I'd probably try a herd restart guix-daemon. <FrenchNewbie>i have another question, did someone successfully seted up pam.mount ? <FrenchNewbie>i have an old pam_mount config and would like to adapt it in guix config.scm <dcunit3d>for some reason, the "environment-variables" script exports vars referencing "guix-build*-1.2.3.drv-0" instead of "*drv-1". idk. I'm going to clear those out and try with the first set of build files <Rutherther>dcunit3d: you can of course just use guix shell --share to mount it to the right folder <FrenchNewbie>is it possible to login as linux user and then make pam_mount ask for windows user to mount the shares ? <FrenchNewbie>or do i have to setup a pam login service that makes me connect with the windows logins credentials <FrenchNewbie>when i read the pam_mount entry in the wiki i see that you have to declare which users are needed to mount <FrenchNewbie>and i want that info to be a variable based on user logged in or beiing asked to type it <tae>I have r, python, python-rpy2 and r-lintr installed. But somehow I cannot call lintr from Python. <tae>>>> from rpy2.robjects.packages import lintr <tae>ImportError: cannot import name 'lintr' from 'rpy2.robjects.packages' (/home/user/.guix-profile/lib/python3.10/site-packages/rpy2/robjects/packages.py) <dcunit3d>Rutherther: heh the repo has just needs the paths adjusted for the `go install` command <jas>hi! i got two different containers when running 'guix pack' with identical parameters and identical guix checkouts. do different substitution servers have different content? or what could explain this? <Rutherther>jas: could you elaborate how differnt they are? like the hash of the produced tarball doesn't match? <Rutherther>different substitution servers definitely aren't supposed to have different content, that would mean there is an issue, but it can happen that something isn't 100% reproducible <Rutherther>FrenchNewbie: what field does it say that is invalid? <jas>i will do a html diffoscope, probably the simplest <Rutherther>jas: and are you sure all channels are the same? (/or that package is not picked from different channel) <FrenchNewbie>i defined it at the same level of users or services, in operating-system <Rutherther>FrenchNewbie: did you make something like (pam-mount (define pam-mount-rules)) then? You need to put only valid fields in the constructor... <jas>yes, this is running the same commands in two different containers: one built from debian12 with guix from apt-get install and one with guix from ./guix-install.sh <FrenchNewbie>i got a pam-mount-service-type definition with pam-mount-configuration\n rules pam-mount-rules in services <jas>so both guix installations should be fresh. and 'guix describe' point to the same commit id <Rutherther>FrenchNewbie: I don't understand what you mean by putting it at the same level of users or services, there is no pam-mount field for operating-system... <jas>the artifacts can be downloaded by clicking 'Download' and do a diffoscope on them. but i'll try to get that up on a website for easier review <Rutherther>FrenchNewbie: I don't know what you're trying to do, it can of course be in pam-services field of operating system <Kabouik>Has anyone ever attempted installing WithSecure antivirus on Guix? I am pretty sure it's of almost no use, but this is a policy enforced by my institute for Linux machines on the network, and I'm trying to negociate the right to keep Guix as well as admin rights, so the antivirus is probably not something I can negociate too. <Kabouik>Is there a similar policy at INRIA civodul? <FrenchNewbie>puting my define at the same level as pam-mount-service-type gives me "definition in expression context, where definitions are not allowed" <Rutherther>FrenchNewbie: you cannot put define wherever... I don't understand why you even are using it <Rutherther>a global variable, so it's valid only in 'global' scope, certainly not in constructors <jas>many of the difference in that output is just confusing: for files with different names, i think the problem is that they have different names, not their different content <Rutherther>jas: locale files are different, that seems a bit like you have a different locale on both machines. There can be a few things that depend on the locale <Rutherther>FrenchNewbie: the example is not complete at all, it just shows an outline of what needs to be done. You put both things at completely different places. The define goes above your operating-system constructor, the service pam-mount-service-type goes into the list of services in your operating-system services field <jas>Rutherther: the locale files were created by 'guix pack', why would the machine locale influence it? the machines are two fresh debian12 containers with no locales installed <jas>Rutherther: guix-daemon is launched with env LC_ALL=C.UTF-8 in both environments <Rutherther>FrenchNewbie: you need to use the module that has that service <jas>Rutherther: maybe i found the issue, one missing: GUIX_PROFILE=/root/.config/guix/current; . "$GUIX_PROFILE/etc/profile" <jas>re-running this, we will find out on roughly 45 minutes... <FrenchNewbie>adding pam-mount in use-service-modules gives me Wrong type to apply: #<service-type pam-mount 7f6aac8fed80> <Rutherther>FrenchNewbie: see the page you sent from the manual <FrenchNewbie>wiki says "The (gnu services pam-mount) module provides a service allowing users to mount volumes when they log in. It should be able to mount any volume format supported by the system. " <Rutherther>oh wait you put it to use-service-modules, then it's fine <Rutherther>jas: I mean you've used --save-provenance, so you should be able to check if the channels used are actually the same from the outputted image. No need for rerunning it with that source <Rutherther>please find what cons* function does, and look at the example, you're calling (applying) pam-mount-service-type, instead of creating a service by calling the "service" constructor like the example does <FrenchNewbie>now i get 'services' field must contain a list of services <jas>Rutherther: where is this provenance stored? <Rutherther>jas: should be in the profile folder that is built <jas>Rutherther: diffoscope doesn't mention it as far as i can see, so the manifest files are identical <Rutherther>it's not in the manifest file, it should be in the channels.scm file that should be in the profile <jas>Rutherther: they are identical (same sha256) however the profile directory name is different in the two builds <jas>what determine the profile path name? <jas>container 1: /gnu/store/m7278cq1lq6bmspm84df7vp0zarq973b-guix-1.4.0-35.a9239a7/share/guile/site/3.0/guix/channels.scm <jas>container 2: /gnu/store/2397bwfsnwnps5pr5dd542nq224c4yrw-guix-1.4.0-35.a9239a7/share/guile/site/3.0/guix/channels.scm <Rutherther>there should be a profile folder that should have channels.scm in the root <jas>there is no other channels.scm anywhere, i recursively unpacked both containers to inspect things <jas>however i suspect failure to run GUIX_PROFILE=/root/.config/guix/current; . "$GUIX_PROFILE/etc/profile" may explain this <Rutherther>FrenchNewbie: as I was telling you, look up cons* documentation <jas>one of containers were not invoking that after guix pull but before guix pack <Rutherther>if that is it, it would mean you've used different channels which should be obvious from the provenance <Rutherther>there should be a profile folder that should have channels.scm in the root <jas>Rutherther: root directory? as in / or /root? <Rutherther>FrenchNewbie: as I was telling you, look up cons* documentation <Rutherther>jas: I don't recall how the docker images look like, so I am not sure where it will be. And maybe I am wrong and there should be no channels.scm file for that, maybe it's just the manifest which should have the channels. The channels under guix package you found aren't so relevant, as if you do guix pack guix, you aren't packing the used guix, you're packing the package named guix which points to a pinned guix being days to weeks old. <FrenchNewbie>i'm getting dependencies build errors but i guess thats the "wait and retry" solution ? <Rutherther>FrenchNewbie: it depends on what dependencies exactly <FrenchNewbie>builder for `/gnu/store/65n82by1dcvxhd3ljraanqys6i7nj8rm-pam_mount.conf.xml.drv' failed with exit code 1 <Rutherther>errors can be caused by a lot of stuff, so it's not so easy to say if waiting and retrying will help of not, usually not (at least not without pull) <Rutherther>okay, so the config, then I am reasonably certain strategy 'wait and retry' won't work, you have to look at the error and resolve it yourself <FrenchNewbie>its because i copied form my original pam_mount.xml and didn't adapt the '=''s into spaces <jas>one difference is umask: drwxr-xr-x vs dr-xr-xr-x for /gnu/store <jas>same pull, same guix describe, same debian12 image, etc.. does anyone spot any differences? one guix installed via apt-get, one via ./guix-install.sh <jas>but why is umask different in these two containers? shouldn't 'guix pack' make sure umask ends up the same? <Rutherther>I am pretty sure it's the locale differences, on one the locale files created have size 0, so there's something wrong with the locale. And judging by the number of packages that are different (not much), I would expect those are the ones that reference the locale <ieure>Yeah, this seems like the permissions themselves are different, not the umask. <Rutherther>that there is write flag is definitely strange, but not really so alarming, it's not so important. I don't think it's guix pack that takes care of that specifically, it should happen on every build at the end that the write mask is removed <ieure>These are permissions, not masks. <Rutherther>is the write flag on the guix-daemon started from apt or from guix-install? <ieure>umask determines the default permission of newly created files. <jas>yes, i meant permissions not umask. if permissions inside the tarball is different, it won't be bit-by-bit identical <Rutherther>right, but the different permissions aren't in the tar <Rutherther>that there is write flag is definitely strange, but not really so alarming, it's not so important. I don't think it's guix pack that takes care of that specifically, it should happen on every build at the end that the write mask is removed <Rutherther>if you meant the permissions in the tar, then yes, those are taken care of by guix pack specifically, and based on the output you sent it's fine <Rutherther>is the write flag on the guix-daemon started from apt or from guix-install? <ieure>Tarballs definitely store permissions, are you sure they're not different between the outputs? <jas>guix-daemon is started manually by my scripts, see the run1 vs run2 outputs <ieure>jas, Note that bit identical output is deterministic builds, this is not the same thing as what Guix does, which is reproduceable builds. <Rutherther>jas: yes, but as far as I understood from you one of those guix-daemon's comes from apt, one from guix-install <ieure>There is no guarantee that Guix outputs are bit-identical. <jas>Rutherther: yes, but both runs do a guix pull to the same new commit, shouldn't it rebuild a new guix-daemon? hmm.. maybe i need to restart it? yes, that should be it?! <Rutherther>jas: are you starting the guix-daemon twice then? I missed that. <jas>ieure: i got 'guix pack' to produce bit-by-bit identical containers before several weeks apart, so i'm hoping this still works <Rutherther>you would need to 1. start initial guix-daemon, 2. pull, 3. stop guix-daemon, 4. start the new guix daemon that you pulled. I don't see you doing that. <jas>Rutherther: duh, i don't restart guix-daemon. i need to do that after guix pull, presumably? yes, i'm hoping this is the cause <ieure>jas, Sure. But this isn't a property guaranteed by the system, so that may not happen if you do it again. <jas>Rutherther: thank you!! <Rutherther>you don't 'need' to do that, but it's the difference here. That once you're using daemon from apt, once from guix-install. It would even make sense to me that maybe one of those has the locales somehow set wrongly, so you end up with different locale files <jas>ieure: oh. is there any hope to see this property being promised? <Rutherther>ieure: while there is not really a guarantee for bit-for-bit identical outputs, I think that Guix tries to achieve it as much as possible (ie. see the change of guix package forbidding parallel builds just because it would produce outputs that aren't bit-for-bit identical) <ieure>jas, Probably not. I think it'd be nice, but there's foundational issues with it, like, there are compilers in Guix which themselves aren't deterministic. <ieure>The Clojure compiler is one, but I'm sure there are others. <ieure>Okay, so I found that docker-compose in Guix doesn't work at all anymore, and set up rootless podman. <ieure>But now my docker-compose setup doesn't work because it's not run as root so it doesn't have permissions to read or write the bind-mount attached to the container. <ieure>docker-compose is fully broken in Guix and no longer works at all. <ieure>But before that was the case, it worked, and I'm confident that a system with a functioning Docker setup, it would. <ieure>Do I need to chown the files the container needs to access to my user account? I don't really understand the subuid/subgid stuff used in rootless podman, so I'm not sure if they need to be owned by my user or some other one. <ieure>Alternately, I could use an oci container in my system config, *but*, I would need to make it not automatically start. Since Guix's ZFS setup is also pretty busted, and the bind mount the container needs is on a ZFS volume, which I have to manually mount on every boot. <ieure>If the container starts before I do that, it'll use / and fill up my disk. <ieure>I'd prefer to keep the compose setup, since that make the whole setup portable -- I can put the disk on any computer and start the container and it works the same. <Tadhgmister>does guix have any way to load kernel modules other than the ones compiled with the kernel? I see openwrt manages some of the kernel modules with its package manager instead of the kernel and was wondering if anything like that is done in guix <Tadhgmister>like right now the guix kernel config files specify that the kernel should be compiled with iptables support as modules, but unless you use iptables system service or related most users wouldn't necessarily need that installed on their system <Tadhgmister>and if you do enable that system service it has an extremely natural place to specify some additional kernel modules should be loaded <Rutherther>Tadhgmister: I am pretty sure it's possible to load modules compiled out of tree, that's what the kernel-loadable-modules field of operating-system is for <Rutherther>and you can definitely add modules frommmservices through the linux-loadable-module-service-type <Tadhgmister>yeah I'm just finding this now, iptables doesn't do it when it could but it definitely does exist <Tadhgmister>wait, so it defines linux-loadable-module-service-type in gnu/services.scm and it is referenced in tests and docs but never called by any other code? <Tadhgmister>does it get complicated with version compatibility or something? I'd expect at least *one* system service to load some kernel modules <Rutherther>Tadhgmister: I suppose it wasn't needed as all the modules needed are in kernel itself. I would expect minor version incompatiblity issues if modules from kernel-tree were used without checking the actual kernel version used. I think checking the kernel version used could work, by extending linux-builder-service-type directly, but it's going to be a bit painful ant not 100% (if extension has overriden it, you might not spot it) <Rutherther>potatoespotatoes: I have no idea what you're asking, but going to guess that you might be interested in the plain-file gexp procedure. <Rutherther>potatoespotatoes: I have no idea what you're asking, but going to guess that you might be interested in the plain-file gexp procedure. <ieure>Rutherther, Client's doing it again. <ieure>Rutherther, You're using some kind of IRC bridge? <Rutherther>yes. But the bridge is not the issue. The issue is that my matrix server is seemingly being overloaded at some points in time. Usually happens only after like a week of usage, but now it's after a day. <ieure>I run Matrix, I aspirationally wanted to set up an IRC bridge, but I ran screaming after I looked at that stuff. <Rutherther>but now the latency is fine, so I don't know why the message got resent <ieure>You don't see when it happens on your end? <Rutherther>no, not at all, it happens quietly, I can only check the logs on logs.guix.gnu.org <Rutherther>I think the matrix server sends the message to the bridge appservice multiple times because it thinks the message hasn't been delivered or something, but it has been <Rutherther>I am starting to get frustrated by it because I don't really think my server is overall overloaded, the cpus can be hitting 100% sometimes, but only temporarily, it's not like the server would be 100% overloaded all the ti <Rutherther>I don't know if this is a specific of the Conduwuit matrix server I am using or every other server would be doing it as well, but migration is not really possible without getting rid of all the data <potatoespotatoes>Rutherther: I'm trying to use text-file* but I don't understand what module I'm supposed to import for this. I thought it was in (use-modules (guix build utils)), would you be able to help? <Rutherther>potatoespotatoes: if you want help, you're going to have to share more details about where you want to get your file specifically. It's not so easy to answer your question without that. The most important is if you're in the build context on the daemon side or not <potatoespotatoes>Rutherther: I'm trying to write a wrapper around a binary and pass a command line argument. The argument takes a file that I am generating in guix (so I have the string representation of the file in hand). <potatoespotatoes>the thing that is broken (I'm currently trying to fix) looks like: (let* (... [libfile #~(text-file* "libraries" libfile-str)]) (wrap-program (string-append #$output "/bin/agda") `("AGDA_LIB_FILE" = (,lib-file)))) <potatoespotatoes>which doesn't pass any arguments to /bin/agda, but I figure if I could get it to work it would be a good start <potatoespotatoes>RE: install hook: I'm running this in a (modify-phases %standard-phases (add-after 'install 'wrap-agda-binary (lambda ...)) <Rutherther>your code doesn't look right, first of all I don't unerstand why you're trying to use text-file* in this context when plain-file is used in gexp context, second, it doesn't make sense to gexp it, you need to ungexp it, not gexp it, inside a gexp expression that you should have over the whole modify-phases. <potatoespotatoes>Hmm... I get an unresolved gexp when I just gexp #~(modify-phases ...) and try to simplify, I'll work through that. <Rutherther>which is what you have if you haven't changed what you sent previously <Rutherther>or you possibly have it quoted, I don't know, not enough context <Rutherther>or you possibly have it quoted, I don't know, not enough context <potatoespotatoes>okay, I've minimized all of the gexp errors, but plain-text is now an unbound variable <Rutherther>are you ungexping it? do you have guix gexp imported *inside the whole file, not build context!* <potatoespotatoes>Now, I've only got #~(modify-phases ...) with no gexp quoting/unquoting, and I'm calling (plain-file "libraries" lib-file-str), but the error is "ice-9/boot-9.scm:1685:16: In procedure raise-exception: <Rutherther>it is not supposed to be called in the build context <potatoespotatoes>That yields: guix build: error: #<procedure plain-file (name content)>: invalid G-expression input <Rutherther>so that is your problem then, you have it inside of the build context <Rutherther>you can't pass something from the build context back to the evaluation <Rutherther>if you wan to use plain-file, yes. If you want to do it all in build context, use something else like with output to file or call with output file <Rutherther>so that is your problem then, you have it inside of the build context <meaty>does 'guix package -u' upgrade packages in both the "home" profile and the one "guix package" modifies or just the latter? <potatoespotatoes>the file I'm generating comes from the package inputs, which is why I was using plain-file in the build phase... I guess I can pull this out of the build context and generate the file outside of the phase. <Rutherther>if you want to do it in the phase, just use with-output-file or something else that generates the file there <Rutherther>meaty: it doesn't touch your home environment at all <meaty>Rutherther: so the procedure to upgrade to all the latest packages (and have them all derived from the same version of guix) would be 'guix pull && sudo guix system reconfigure sys.scm && guix home reconfigure home.scm && guix package -u'? <Rutherther>yes, and even that doesn't guarantee it as you can have pinned packages in the user profile, which guix package -u won't upgrade <ieure>meaty, It is inadvisable to mix regular Guix profiles and Guix Home IMO. <meaty>ieure: why so? guix package -i/r/u is faster than guix home reconfigure, and I just "upstream" the packages I'm committed to to guix home every once in a while <meaty>Also this way if I roll back I won't have an out-of-sync file to worry about <Rutherther>if you want to do it in the phase, just use with-output-file or something else that generates the file there <Rutherther>meaty: it doesn't touch your home environment at all <meaty>Rutherther: wdym? I don't see a 'guix home roll-back --with-output-file' in the manual <untrusem>what could be the process to switch to wayland from xorg <untrusem>I would also like to setup xwayland later <meaty>untrusem: Add a wayland compositor package to your system profile and you should see its session as an option in your session manager <meaty>untrusem: xwayland is a feature (specifically a "protocol") of wayland compositors, not a separate package, so it should "just work" iiuc <meaty>I've never needed to configure xwayland <meaty>You can also start a wayland compositor just by running it from the command line, it's much simpler than x11 <Rutherther>yes, and even that doesn't guarantee it as you can have pinned packages in the user profile, which guix package -u won't upgrade <dajole>How can I figure out where to find git-prompt in guix? I have found the git completions in `~/.guix-profile/etc/bash_completion.d/git`, but I can't seem to find git-prompt. <untrusem>what wayland compositor do you folks use? <untrusem>I see setting up wayland is very much different based on person <untrusem>Rutherther is using dwl, I think that custom one, anemofilia is using river <meaty>you don't "try wayland" so much as you try a compositor <meaty>"wayland" is just an API standard, it doesn't have a direct effect on the user experience <meaty>no I was wondering what Rutherher meant to say instead of repeating himself <meaty>untrusem: xfce is working on wayland suport no? <gabber>is arm-none-eabi-gcc supposed to be part of the package gcc-cross-avr-toolchain? <gabber>or: where can i find arm-none-eabi-gcc? <Rutherther>the toolchain is produced by the make-arm-none-eabi-toolchain-12.3.rel1 procedure <gabber>Rutherther: so.. can i include whatever this procedure evaluates to in a shell? <gabber>i'm trying to run `qmk setup` which for some reason needs arm-none-eabi-gcc <lechner>Rutherther / about the empty files on reboot problem, should (or does) reconfigure call sync? <Rutherther>I don't know if it should, I woud think it's not responsibility of it, but hard to say <lechner>Rutherther / would any of the issues have occurred if it had synced? <Rutherther>lechner: not in their current form, but possibly yeah. The files from reconfigure wouldn't be affected, but other files still could be. <Rutherther>that the files produced during guix system reconfigure is just caused by the fact that most people go directly for reboot after that <lechner>Rutherther / I'd like to propose in the list thread to insert a sync call. Would you like me to mention that you agree (if you do) or should I sign alone? <gorilla>"Hardware Considerations" points to the FSF RYF certification for certified devices. The newest certification there is from 2023 and is for a router. The newest anything that resembles a pc/laptop is the Talos II motherboard from 2019. <gorilla>I have made a handful of attempts at Guix with different machines, but each time I run into nonfree firware walls. <gabber>gorilla: unfortunately, this is the state of modern computing <gorilla>So I'm trying to find a list of commercially-available systems that just work with Guix. <gorilla>I imagine that there are plenty of people who have found some rig that works. <gabber>didn't try any of these with pure Guix but what about Purism, MNT Reform, frame.work <gabber>gorilla: i am not sure your last statement is true <gorilla>I have tried a machine that worked except for the wifi, another that worked except for the video adapter, etc. <lechner>I'm pretty sure most of my equipment, although ancient, works with stock Guix as long as I don't use wireless networks. <lechner>i don't think it meets FSF guidelines, however, due to the processor microcode (which had serious bugs) and the Intel Management Engine, which is extremely hard to turn off <Rutherther>lechner: I can't currently say if I agree or not, will have to give it some more thought, I am inclining to not agreeing as it seems to me programs writing to the disk should just write and let the OS handle it <jlicht>good news: tarsius (of magit fame) seems to be interested in adding better Forgejo support in the future to emacs-forge \o/ <duncan>it's easier buying desktop hardware, in terms of chucking the wireless card problem down the road, but I'm not sure there are discrete GPUs which work without loading proprietary firmware (integrated graphics may not have this problem) <ieure>iGPUs have the same problem.