IRC channel logs
2023-10-24.log
back to list of logs
<TehBoss>if i use guix home can i still use `guix install`? <TehBoss>also will guix home overwrite files that already exist? <bumble>yes you can still use guix install but, of course, packages installed that way won't be reinstalled or updated by guix home <bumble>yes guix home can overwrite files that already exist <bumble>for example, if your guix home creates ./config/emacs/init.el it can overwrite a file that is already there <bumble>I'm not sure I guess it depends on which file you don't want to overwrite <TehBoss>i don't wanna overwrite any files, the only file i'd want it to write is .profile so it can start shepherd <TehBoss>maybe later i'd consider getting it to do more, but i'd liek to take it in small steps <bumble>I'm probably the right person to answer but essentially guix is only write files by default that are needed by guix... if guix home is writing files that is because your guix home configuration specifies, in some way, that those files should be written <bumble>s/I'm probably the right/I'm probably not the right/ <TehBoss>(i haven't yet tried it, i'm just making sure i wont screw up my stuff) <bumble>there is probably no reason to be afraid <bumble>if you didn't specify any xdg or home configuration and did not specify any bash or profile vars or anything like that, guix home won't write anything in your home space <bumble>the situation where, for example, it would write a ./config/emacs/init.el would occur because you have explicitly defined an init.el for your home config and have added the directives to your home config file that would explicitly copy that file into ~/.config/emacs/init.el <TehBoss>would it not put it in .emacs.d/init.el? <bumble>your home configuration would define where it is copied <TehBoss>alright i'll have a go making a guix home to start emacs on login <bumble>your configuration could be setup to copy it to .emacs.d/init.el or it could be configured to copy it to XDG_CONFIG_HOME or wherever you want <TehBoss>should i put m yhome config in ~/.config/guix-home? <bumble>I think there is a home configuration from unmatched-paren which does start emacs on login <TehBoss>i guess it doesn't matter where it goes <bumble>I keep my home config in a git-cloned repo at ~/software/guix-home/guix.home.scm <bumble>so you could keep your home config whereever you like <bumble>I usually update home this sort of way `guix pull && cd software/guix-home && guix home reconfigure guix.home.scm` <TehBoss>does this line just append my old bashrc onto the one guix generates? <TehBoss> (bashrc (list (local-file ".config/guix-home/.bashrc" <TehBoss>if i've made a package how do i install it with guix home? <TehBoss>guix home complains that the package is unknown, i'm guessing because i made the package <bumble>guix package --install-from-file=mypackage.scm <bumble>I think that's how its done its been awhile since I've done it <TehBoss>yeah i installed it, but it doesn't work in my guix home configuration <TehBoss>after removing it it still doesn't really work because i've got ~/.config/guix-home as a symlink to ~/.dotfiles/.config/guix-home <TehBoss>doesn't work if i try using ~/.dotfiles/.config/guix-home/home-configuration.scm either <TehBoss>guix home: error: canonicalize-path: No such file or directory: "/home/boss/.dotfiles/.config/guix-home/.dotfiles/.config/guix-home//.bash_logout" <bumble>I'm not sure and I'm confused or distracted by the choise to use this path ~/.dotfiles/.config/etc <bumble>I think it is unconventional to store configurations inside any dot file <bumble>specifically, guix home and guix system configurations, that is <TehBoss>well i'm using gnu stow and then putting all of my important config files in .dotfiles then running stow . inside the .dotfiles directory <bumble>ACTION has not used gnu stow before <VesselWave>Hello Guix! How to put a new system Shepherd service into Guix System definition. I want to autostart something one-shot <apteryx>these new texlive "schemes" collection look useful <apteryx>ACTION runs 'guix install texlive-scheme-minimal' <jaeme>I want to package the rust implementation of age ("rage") in guix but theres already a package named rage <jaeme>Should I just name the rust package "rage-rs" or "rage-rust" or "rust-rage" <jaeme>Rage is on crates dot io as well <oriansj>guix really should allow package name spaces and enable the users to decide on the names they wish to use <oriansj>so that when one does: (cons (channel (name 'variant-packages) (url "https://example.org/variant-packages.git")) %default-channels); they would be able to use any names they want for any packages and they could be referenced like variant-packages:foo <the_tubular>Somebody here already recommend a course on scheme, I forgot the name <iank>bordeaux.guix.gnu.org: host not found: System error <apteryx>./pre-inst-env guix system image gnu/system/examples/vm-image.tmpl wants to authenticate 65 516 new commits and fails on 330b94e8bd88baf903d2bc11bf96e23b119e0fe5 <iank>heh, sorry i got no idea <apteryx>ipv4: 5.9.105.58, ipv6: 2a01:4f8:162:411a::3 <iank>it works for me outside guix, but not inside <adanska>i tried to roll back my generations but i couldnt seem to find anything <iank>vivien, thanks. ran it, but no luck <spine-o-saurus>also before i run install is there way to change blocksize before creating filesystem? <lilyp>TehBoss: that's right, Guix uses it's own ld.so – if it breaks your application that means it wasn't all that statically linked after all and you might want to patchelf it <efraim>futurile: at some point with the crates (like with winnow) I cut off the old versions with #:skip build? #t ; Cut the dependency graph <efraim>otherwise it can go on forever with old versions <adanska>this error is so strange. libpciaccess is a dependency of icedove.. <adanska>im going to do a guix time-machine and see if thats where the regression happens. <efraim>colord fails its testsuite on powerpc-linux but I'm not convinced it's a spurious failure <adanska>from a25a492f2b8604de4ebc21298f24891a1a245161, the commit before <efraim>debian skips the test suite on big-endian machines, no upstream bug :/ <adanska>in the meantime, would anyone else be able to try and run icedove and see if they get a similar error? <futurile>efraim: OK, makes sense. I emailed my patches in #66717, explaining the specific conflict in the cover-letter. <adanska>whats up with icecat failing to build on ci ? <efraim>might still be baking the substitute <adanska>maybe... its suspicious considering im having icedove issues.... <adanska>i mean youre right regarding the substitutes <adanska>but like generally. in a holistic sense. <adanska>why does doing 'guix build --check=2 --no-substitutes --no-grafts icedove' do nothing but return a path to a build in the store? <efraim>futurile: seeing that all of librespot is in github.com/librespot-org/librespot, and assumably developed together, would it make sense to just package "librespot" as one package and use the workspace as one package? <adanska>it doesnt even look like its attempting anything <rekado>adanska: because it has already been built <adanska>btw, putting it out there again, i would be super appreciative if anyone running the latest guix commit could see if icedove/icedove-wayland works for them <futurile>efraim: hah - never thought of that - as the importer split them up. They are really 'one thing'. Do you care that some parts are buildable from source (e.g. core/connect), but due to the jack issue 'playback' won't be - as one package would all of it have to skip source building? <futurile>efraim: also is there an example package that does this <efraim>I only realized now when looking at why it may not build. You might have to choose a specific backend(s) for playback so we can test it out <adanska>ok, i deleted my .thunderbird file and it seemed to fix things. it didnt get rid of the warnings about libpci though, but maybe that was a red herring <efraim>20 hours to build rust-1.73 on aarch64-linux <efraim>2 cores on a rock64, with that type of burn-in test I should see if 3 cores will work or overheat <fnat>if i launch "$(guix system vm config.scm)", log in, and guix pull - i get an error about the store being on a read-only filesystem <fnat>this is expected, isn't it? <fnat>if i want to be able to guix pull from within the vm, i imagine i should simply build the image and launch it directly with qemu, instead of using the "guix system vm" script? <fnat>i hoped there could be a way to make use of the host's store while being able to install additional packages (from the guest system) - but that's probably a naive expectation? <efraim>fnat: perhaps something with the --volatile flag would help? <efraim>futurile: I see what you mean about the conflicting demands on the jack library <fnat>uh, that looks promising, let me try that - thanks efraim <fnat>volatile seems to be the default for "guix system vm", or was it meant as an option for "guix system image" instead? <fnat>i'd tried "guix system vm --persistent config.scm" already - which also complained about the store being on a read-only fs <futurile>efraim: we don't have the option of ignoring optional crates with the cargo-build-system right? The only other 'mad' thing I could think of is does it work if we alter the Cargo.toml so Guix's build doesn't receive the optional dependency? <efraim>futurile: Right now I'm playing with a snippet to have cpal-0.13 accept other versions of jack <efraim>the difference between 3 cores and 4 cores for librsvg was 66 minutes vs 60 minutes. I'll set that machine to 3 cores to leave overhead for it to panic <apteryx>why is the guix channel updated upon doing './pre-inst-env guix system image gnu/system/examples/vm-image.tmpl' ? <apteryx>it outputs: Updating channel 'guix' from Git repository at '/home/maxim/src/guix/'... <hako>efraim: Yes, Hilton Chain here. <efraim>hako: I saw you were packaging the next version of zig, I wanted to see if you were able to get it to build with an earlier version of zig <hako>"zig build" using zig@0.10.1 in the source tree of zig@0.11.0 gives me an error: "error: invalid builtin function: '@intFromEnum'" <mirai>efraim: re #66641, perhaps we could get 1/2 into core-updates instead? <efraim>yeah, that wouldn't be a problem <efraim>ok, it's been pushed to core-updates <apteryx>fnat: I don't think you can do any store operation in a 'guix system vm' <apteryx>you'll have to use 'guix system image' and boot this with QE <apteryx>QEMU or one of its frontends (virt-manager, GNOME Boxes) <apteryx>is someone able to use guix from their checkout to build a system? E.g.: ./pre-inst-env guix system build gnu/system/examples/bare-bones.tmpl <apteryx>I think what is special about vm-image.tmpl is the use of a (guix (current-guix)) package inside its guix-service-type <fnat>apteryx: hey, thanks - that makes sense, i'll keep on using the two-step process then (image + qemu) <apteryx>fnat: if you have a lot of time on your hands you could look at the QEMU script produced by 'guix system vm' to see how it exposes the host store <apteryx>and perhaps try to expose the host daemon socket and have it used with GUIX_DAEMON_SOCKET inside the VM. <apteryx>I guess just sharing the daemon socket is enough (only the daemon requires special access to the store) <fnat>thanks apteryx - i've noted this down, i'll experiment a bit more later today <apteryx>ACTION is working on fixing bug#57068 <apteryx>I got passed my './pre-inst-env guix system image gnu/system/examples/vm-image.tmpl' issue somehow; I think by building it with regular guix instead of (current-guix) once. <apteryx>the offending commits got authenticated correctly in the non ./pre-inst-env environment, then I could use it <mirai>Building the following 31 packages would ensure 83 dependent packages are rebuilt: … <mirai>should I send this to core-updates? <mirai>since it's “round the corner” <nmeum>I would like to upgrade unicorn to 2.0.1 and I noticed there is already an open issue from may which hasn't received any attention https://issues.guix.gnu.org/63442 the patch changes the unicorn package quite a bit and only ships the python files, is that why it hasn't received any attention? what would be my best course of action to get the package upgrade applied? should I send an <nmeum>also: presently unicorn fails to build because the tests don't pass, with the patch referenced above it builds again <futurile>nmeum: did you check whether a team looks after that package (using teams.scm) - and did you cc them onto the patch when you sent it? <nmeum>it's not my patch, I was just looking for the issue tracker if someone else already send in an upgrade <futurile>nmeum: if there's no replies or conversation on it - then it might be that no-one saw it. You could try building it, bumping the conversation and making sure that the Python team is aware of it etc <futurile>nmeum: there was a conversation a few days ago on guix-devel about what sorts of patch testing help. Worth checking that out. <phf>Hi! If `input_1' is an input, say `("samovar" . "/gnu/store/pgw9...samovar-1.0.2")', then is there a way to get its associated source file `/gnu/store/pgw9...-samovar-1.0.2.tar'? <elevenkb>Hey there is there anything like envrc for guix shell --container? <stevenroose>Hey all. I keep losing my syncthing configuration (I think on reboot, could be reconfigure or update, I don't check often enough), does anyone know what could be causing that? <stevenroose>I have the syncthing-service-type enabled for me user. I saw some recent patches for a home-syncthing-service-type or so, is that going to solve this issue? <stevenroose>I can't find an issue for this in the issue tracker. <phf>`(package-source pkg)' I guess but then, how to get from `"/gnu/store/pgw9...samovar-1.0.2"' to `pkg'? <elevenkb>stevenroose: How do yoset your syncthing configuration? Using the web interface, or perhaps a syncthing-configuration record in your configuration file? <elevenkb>As for my question, I'll probably launch the shell using a script that I'll place at the root folder of the project. <phf>Looking at ̀(guix packages)' API. <stevenroose>elevenkb: hmm, do you think the web interface isn't being persisted somehow? <futurile>nmeum: hmm it was probably in the middle of the massive thread about cognitive overhead for contribution. Anyway, I think the substance was that testing that a patch actually works (not just that it builds) is helpful. And there's kind of a checklist on the qa.guix.gnu.org <stevenroose>IIRC last time I reconfigured I tried to restart the service, but I'm not sure I actually managed to do that (right now I can't find any services using shepherd for synthing anyway) <phf>Just string-append ? <jpoiret>phf: no, unless you also pass the source as an input <phf>jpoiret: if the execution reaches a `lower' function in `(guix build-system mix)', then we have access to the `inputs' of the package being compiled. If `pkg' is an element of `input', then is it possible to get the source of `pkg' here? <phf>*If `pkg' is an element of `inputs'... <jpoiret>where do you want to use the source? <vivien>Splitting a commit is not very fun. How do you do it? What I do is consider the base commit, revert⁰. I revert it, then revert the revert. I then rebase the revert¹ and revert² on top of revert⁰. Then, I edit the revert¹, stage the changes of revert², discard some, continue; fix the conflict in revert², finish the rebase. Then, I reword revert². Then, I fixup revert¹ on top of revert⁰. Then, I reword revert⁰. Pfew. <jpoiret>in the build expression or outside of it? <phf>When execution reaches the `install-dependencies' phase of the build side procedure called `mix-build', I need to have access the the source of each Erlang and Elixir dependencies in order to convince `rebar3' to not access the network. <jpoiret>yes, then there you don't have access to the sources of the inputs, you need to also pass them as inputs <futurile>vivien: 'as a hobbyest' I find git very hard - been using StackedGit which deals with everything as patches on top of git. It's quite nice - and git is underneath so you can fallback to git if needed. <phf>It is desirable for the user to just specify inputs as usual, e.g. `(inputs (list erlang-samovar))', but then, I need to deduce the source of `erlang-samovar' using some kind of procedure. <phf>(when defining a package) <futurile>the_tubular: ah ofc - I'm a weird non-emacs developer =-) <phf>jpoiret: Ok, so it means that it should be doable in the client side `mix-build' in `(guix build-system mix)', is that correct ? <jpoiret>you'd need to identify the dependencies you want to include the source of <phf>sneek: later tell jpoiret How to go from `#<gexp-input native #<origin "https://repo.hex.pm/tarballs/samovar-1.0.2.tar" #<content-hash sha256:1nfw5vbzcvqzpsahwxz7zjlshg31pa9f306g3hzm1kfx5rsyvry4> () 7f9c3ee0c900>:out>' to `/gnu/store/pgw9...-samovar-1.0.2.tar' <phf>sneek: later tell civodul How to go from `#<gexp-input native #<origin "https://repo.hex.pm/tarballs/samovar-1.0.2.tar" #<content-hash sha256:1nfw5vbzcvqzpsahwxz7zjlshg31pa9f306g3hzm1kfx5rsyvry4> () 7f9c3ee0c900>:out>' to `/gnu/store/pgw9...-samovar-1.0.2.tar' <mirai>I assume it's for debugging purposes only <phf>mirai: Thanks. Well, I need that thing to convince rebar3 to stop fetching things from the network and just compile things. <phf>If erlang-samovar is a Guix package that is an Erlang dependency of some Erlang project, then _checkouts/samovar/src/ should contain the sources. <phf>at the moment that `rebar3 compile' is called. <phf>mirai: « Within a gexp it's just #$… ». `/gnu/store/pgw9...-samovar-1.0.2.tar' is needed just before the `build' phase. jpoiret suggested to pass the sources client side. So, in the client side rebar-build function in this case. <VesselWave>Hey, Guix! Does anybody know how to make a system Shepherd service to auto-start something? Or maybe someone successfully made bitcoind a user-level Shepherd service? <mirai>when you add a service to (services …) it already autostarts <redacted>I've configured my nginx service in scheme. If I wanted to modify the nginx configuration file from another service (such as in a hook, or in a mcron script), how might I go about doing that? <redacted>An nginx configuration is a data type, so perhaps it's possible to modify that data type and write it to disk? <ohyllad>If i have two processes running in their respective guix shell --containers, is there a way to allow one to connect over http to the other? <nckhexen>vivien: That is... 2 levels of metapatching? And I thought I was pushing git commit -p, 'e' to the limits of sanity (and diff validity) o_O <lechner>Hi, as an eshell user i'm often startled to find myself in Bash after a 'guix shell'. Is there a way to select the shell (perhaps an 'emacs-client' with an shell?) What does 'guix environment' do? Thanks! <lechner>sorry, i meant something like emacsclient -e "(eshell)" <lilyp>lechner: guix shell respects your $SHELL environment variable – eshell just doesn't set it <lilyp>imho guix-eshell might be a feature for emacs-guix <vivien>nckhexen, I don’t want to add anything in the process, because I could forget to redo a change. With my technique, I only discard changes. The worst that could happen is a change ends up in the wrong side of the split. <vivien>I’m sure it is possible to achieve the same thing with less steps though. <nckhexen>Yeah, but yours has better checkpointing. <vivien>lilyp, I can build webkitgtk and gstreamer on my end (x86_64) with the glib.scm updates. We will see if QA can too. <vivien>Thank you cbaines for the work on QA! <vivien>Now I see a [arguments]: Update the style. in the last commit, instead of [arguments]: Convert to list of G-Expressions. <vivien>I did not fix all commit messages, I let the last one through <vivien>Yes, but maybe they are still in the pipes <lilyp>thanks for the heads up – if it's just that, it'll be an easy fix <lilyp>oof, it's appstream-glib ._. <lilyp>oh, wait, that's just the commit msg <lilyp>okay, that + 17/17 both need a reword; seems doable so let's just wait for CI to light green <vivien>Would the etc/committer.scm script help me here? <vivien>I think I should learn to use it <elevenkb>Hmmm, what's missing so that electron apps can be packaged in Guix? <elevenkb>futurile: ah ok,,,, but surely some of them can be upstreamed to Guix itself... like e.g. Jitsi Meet and the Element client for Matrix.