IRC channel logs
2023-06-24.log
back to list of logs
<rubin55>If I would want to place a file somewhere on the guix system, where it is saved and becomes part of a recreatable config - how would one go about doing that? <rubin55>what abstraction do i need to read about? <ChocolettePalett>Will it be located under $HOME directory? If yes, then choose "guix home", and define a service (or extend one using "simple-service) to create a file <rubin55>ChocolettePalett: Well, it is for the $HOME directory of the gdm user, does that count? I want to place a ~/.config/monitors.xml file there <rubin55>Managed to change config.scm to make GDM enable Wayland by default, so far so good. Now to figure out about that monitor.xml.. <ChocolettePalett>rubin55: It might be a wrong way to do this, but you could use "home-files-service-type" described here: <ChocolettePalett>It should create a file in your home directory. Note though, that it uses "guix home": <Kolev>juliana[m], I can't use Guix Home? <HiltonChain[m]><rubin55> "ChocolettePalette: Well, it is..." <- home-xdg-configuration-files-service-type <juliana[m]>Kolev there isn't a home service for it yet if that's what you mean <bjc>i autostart syncthing-gtk, since i like having the gui when i'm on a desktop anyway <bjc>i start it from shepherd in my sway config, but gnome has an autostart mechanism in its settings <Kolev>I added `syncthing-gtk` to my packages list and did `guix home reconfigure` but it did not show up in my profile. <sammm>hi - I am trying to perform a guix system reconfigure based off of a local copy of the guix upstream repo, I've successfully `guix pull --url=....`, but `guix system reconfigure` doesn't seem to build a system that reflects the change I made in my fork. any ideas? <AwesomeAdam54321>sammm: Hi, ./pre-inst-env in your local copy should be used to reflect the changes you made <vagrantc>sammm: does it give any errors or warnings? <vagrantc>sammm: and does "guix describe" show a commit that reflects your changes? <sammm>guix describe does show me that `guix` is pointing to my local copy <sammm>where can I find `pre-inst-env`? <sammm>ah no, still pointing at master <vagrantc>sammm: you've committed your changes to the branch? <vagrantc>sammm: yeah, you still need to tell it what commit or branch to use <vagrantc>using ./pre-inst-env is another approach, where you just use the local checkout (even a dirty one!) ... though it has it's own set of quirks :) <vagrantc>that approach is described in the manual <sammm>okay, I need to sign my commit :) <cel7t>pre-inst-env is the best approach <cel7t>Make sure you have the autocompilation environment variable set to 0 when you are using it though <cel7t>Otherwise you'll have autocompiled files in .cache that'll prevent compilation of changes you make to the files <vagrantc>... but only sometimes ... as i've definitely used that plenty of times without setting that :) <cel7t>I've run into that issue a few times and now I just make sure to set that environment variable before using it <sammm>alright - things are happening! will see how it goes <vagrantc>i waffle between using ./pre-inst-env and ... guix time-machine ... guix pull --profile= ... and just living on the edge and ... guix pull <my crazy branch> <sammm>so after `make` completes, I am hoping I can skip the authentication step and just `guix pull --profile=whacky-changes ... && guix system reconfigure ...` to update my current system to use branch? <vagrantc>sammm: just ./pre-inst-env guix system reconfigure ... <sammm>an aside: has anyone noticed upower being whacky recently? seems to be reporting my battery at 9% max / thinking ac is offline etc - weird <juliana[m]>hmm. what happens if one executes ./pre-inst-env guix pull inside a checkout of the source repo? <sughosha>Hi! I am trying to update all gnome packages. I don't know why we have glib and glib-next. Most of the packages are dependeded on glib. Should I update glib and delete glib-next? <lilyp>sughosha: have a look at the gnome-team branch, kthxbye :) <geri>could someone send me a link to an example how they've split up guix home or system configs? <geri>ive figured out you could create a custom channel for your personal configurations and it's going to add the modules to load path on its own but im not sure how smart of an idea it is <ChocolettePalett>I haven't done that but since configurations are mere scheme files, nothing stops you from writing stuff in several files and then loading them in one entry-point file, so you basically need to figure out how to load external modules in scheme <geri>checking it out, thanks HiltonChain[m] <geri>is the system called dorphine because it gives endorphins? :D <geri>it sounds pretty neat, especially considering its random <geri>my systems are literally called "main" and "T420" atm, i need to exert some creativity on that front <futurile>got to say - really enjoying Stacked Git (StGit) for dealing with guix contributions as patches <futurile>I was using `patman` which is also good. But finding managing a 'stack' of patches really easy with StGit <jlicht>futurile: Could you share any good pointers or tips for using stgit /w guix? I've enjoyed patman, but there have been some rough edges <futurile>jlicht: I started using it yesterday - so bear that in mind - the main problem I have with patman is not the tool, it's my limited ability to deal with moving things around using git: so rebasing, or discovering that the one-commit-per-package is in the wrong order. StGit lets you have a stack of patches, and then it's very easy to move them up or down in the stack, it also has commands to rebase <futurile>jlicht: it's just a very easy user-experience, and as we deal with patches it's well aligned. It also (like patman) has commands to format and send the email. <jlicht>futurile: nice! which version of stgit are you using? It seems guix only has 1.5 packaged <futurile>jlicht: yeah I couldn't get our packaged version to build - so I actually just installed it directly (as I'm on Ubuntu there's a package). <jpoiret>it's a shame people have to create additional vcs tools on top of git <jpoiret>git's patch-driver workflow is not so polished, esp. with the rebase situation <jlicht>jpoiret: The fact that there are so many different approaches makes me happy! So many people, so many preferences <jpoiret>b4 is another tool that has patch creation tools, which works quite well imo <futurile>jpoiret: oh cool - need to check that out then. I really don't enjoy git's ux - 'as a hobby developer' it's too easy to shoot yourself in the foot and takes too much mental energy keeping everything straight <jpoiret>I've gotten used to it and once you're experienced git's ux is quite ok and predictable. But the patch-driven workflow isn't super compatible with git <futurile>Yeah, the slight misalignments between git revisions->format patching->sending email properly - it's quite a lot to get your head around. <alanz>I have found the problem for nncp not building (https://issues.guix.gnu.org/53423). It is a one-liner, need to add (chdir "../nncp-7.5.0") to `go-unpack. What is the best way to have it fixed? Send a patch mail to 53423@debbugs.gnu.org? <geri>for some reason my /etc/profile gets permissions of 600 on system reconfigure, does anyone have the same issue? <geri`>nvm, it's just read and only for root <ae_chep>How can I confirm a Rust library I'm building is building correctly? I don't know how Cargo works, and its only dependent is complaining about a missing dependency. I can't tell if I am packaging the dependent or the dependency wrong <geri`>if its installed by guix doesnt it already mean it's always built correctly, hashes match, etc? <geri`>nvm, misunderstood the question <geri`>so far id only be able to guess by trial and error until it works <ae_chep>For one, my dependency isn't made available in the guix-vendor directory <ae_chep>I did spend some time doing trial and error but I'm out of parameters :) <geri`>i wanted to try updating libnotify to 0.8.2 but build failed so hard i got scared and dropped it for now <ae_chep>Okay, where do I expect to see the packages I'm listing under `#:cargo-inputs` ? guix-vendor or CARGO_HOME? And why might a package be missing from those directories? <lilyp>guix usually guesses the contents for guix-vendor from the package name <lilyp>so if you have a rust package that doesn't start with rust-, things could look bad for you <ae_chep>I named the package "rust-cbqn" . I removed the Cargo.lock file and edited the Cargo.toml file so it refers to "cbqn" not by commit and branch, but by version number <ae_chep>I'll rephrase that. It sounded confusing <ae_chep>On the dependency side, I named the package "rust-cbqn" (both for `define-public` funciton and at the "name" field). I have also edited the Cargo.toml file on the dependent side so it refers to the dependency (cbqn) by version (it was commit & branch) <zamfofex>Hello, Guix! Does anyone know how straight‐forward it might be to apply a Firefox patch to the IceCat package? (I don’t mind rebuilding it, but given the IceCat origin is distinctive, I was wondering if it’s really as straight‐forward as just using ‘with-patch’, or if I need to do something special about it.) <ae_chep>zamfofex: I'd imagine `with-patch` to be sufficient. I'd just test the patch with the source tree locally to make sure <civodul>looks like committers haven't all figured out how to do this :-) <Cairn>Has there been discussion for adding a "maintainers" section to packages? <Cairn>Not sure Guix package usage is urgent enough to justify it <civodul>Cairn: there's been a discussion ca. 2018 maybe to *not* have it <civodul>see commit 154f1f0937754fafac0c6288dd458b66b332e6bb <Kolev>I'm dismayed that `guix system container` req. `sudo`. Podman does containers without it. <Guest28>is it possible to add channels system wide? <whereiseveryone>Kolev: That's yet to be resolved. Someone who has the time would need to work on it. <whereiseveryone>civodul: You're referring to the postgres connection failure in that link? <Michal_Atlas[m]>Hello, is there any way to get code from a channel to be accessible in standard Guix? For example adding custom `(guix scripts foo)` modules and stuff? <civodul>whereiseveryone: i think the code might have been leaking connections <Michal_Atlas[m]>So I could make a package in a channel, and them add a "native-searchpath" of GUILE_EXTENSION_PATH? Am I getting that right? <civodul>that code has changed, but it seems cuirass-remote-worker has troubles now :-/ <lilyp>Michal_Atlas[m]: IIUC your channel should provide (guix extensions ...), but then it works on guix pull <lilyp>though do take a peek at actually existing channels that make use of extensions – I think rde is a popular one <Michal_Atlas[m]>Yeah, I thought I'd find it there, but kept looking at scripts, since I thought channels just got added to the load path 😅😅, now I'm on the right track <mirai>lilyp: re shared-mime-info, do you want me to send a revised series? <lilyp>I can fix the commit messages locally if you'd rather not <mirai>I'm fine with whichever is more practical to you (they were trivial copy-paste mistakes) <lilyp>It's no big deal, I got to work in the merges from master too <Guest28>how good would gnu guix run on a risc v sbc? <ekaitz>Guest28: but it may need some extra work <ekaitz>Guest28: you would need to compile your software -> but that's doable if you have the time <Guest28>well, not working out of the box, no substitutes, doesn't really sound nice. I guess it would be to experimentell <mirai>apteryx: Do you happen to have a system test suite (or anything resembling one) for Network Manager?