<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>... 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?
<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
<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: 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 email@example.com?
<geri>for some reason my /etc/profile gets permissions of 600 on system reconfigure, does anyone have the same issue?
<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?
<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