<pkill-9[m]>the short guide is this: clone the guix source, cd into it, run 'guix environment guix', then run './configure --localstatedir=/var && make', then make changes to the source, and when you want to test them, run 'make' again, and run './pre-inst-env guix ...' to run the guix command using the guix you just modified
<Swedneck>that is so much simpler and less headache inducing
<pkill-9[m]>the second 'make' isnt strictly neccessary i dont think, but im not sure
<pkill-9[m]>yeah i found that part of the guide a little convoluted as a newcomer
<Swedneck>btw how does guix deal with identical packages in multiple channels?
<pkill-9[m]>it prioritises custom ones, not sure about conflicting custom ones though
<bgardner>Good morning Guix; I'm working on adding a new package to guix and getting a couple puzzling messages. I'm accustomed to gnu build system, but this package uses "scons-build-system" so I'm groping a bit. First, "patch-shebang" is throwing lots of warnings about "warning: no binary for interpreter 'python' found in $PATH", but 'which python' shows the correct value (But I am inside "guix environment guix", not sure how that changes
<pkill-9[m]>sinc eyou don't need to install package dependencies, you odn't need to worry that removing a package will break some other package
<JnR>pkill-9[m] Well honestly do you ever get frustrated over alot of missing packages?
<pkill-9[m]>so you can just see what you have installed with 'guix package -I' and remove what you don't use directly, e.g. in the shell or as a GUI application
<JnR>That sounds like exactly what I was looking for. As long as the same content is there
<roptat>JnR, we don't have that many packages compared to other distros, but it's quite easy to contribute more packages
<pkill-9[m]>JnR: I don't, but I learnt how to write my own package definitions for missing things, ofcourse it depends what you use so you'll want to check that everything you want is packaged in guix
<roptat>I have everything I need for daily use, but it could be different for you
<roptat>but I'm cheating: I contributed what was missing for me :p
<pkill-9[m]>JnR: to add to what roptat says, although there are less packages compared to other distros, there are a lot of major packages like blender, inkscape, icecat (firefox quantum de-branded), lmms, krita, obs
<JnR>I actually sometimes compulsively download stupid packages that sound really cool! Then never use them and their 200 dependencies
<pkill-9[m]>those aren't CLI applications, but since they're more complex i think it's a good showcase of what kinda packages guix does have, even if it does have less packages
<roptat>in that case, I find guix environment very useful: it doesn't clutter your profile and it disappears as soon as you exit the subshell
<JnR>I really like that. I've been compiling sources lately anyway to try to keep better track of where my applications are going
<roptat>like, if I need gimp for something, which I usually don't, I'd do "guix environment --ad-hoc gimp -- gimp", and as soon as I quit gimp, it's not available anymore (well, it'll be collected the next time you run guix gc, but it's kept around in the mean time in case you need it once more)
<JnR>I'm going to try the binary install out on my fresh install of my Raspberry Pi test environment
<bavier>rekado: more releases from gnome to go on wip-gnome-upgrades
<roptat>so I've tried to build the disk image for aarch64 with the binfmt. Everything built fine, except for the last package (disk-image): qemu-system-aarch64: -nographic: No machine specified, and there is no default
<roptat>Use -machine help to list supported machines
<roptat>I ran guix system disk-image --system=aarch64-linux gnu/system/install.scm
<Swedneck>pkill-9: sorry got caught up in synapse stuff
<Swedneck>i know how to write simple package definitions now, so i just want to learn to apply them to guix and submit patches
<pkill-9[m]>ok, the rest of it is simple, you just put the code into the relevant module, and check that it builds with ./pre-inst-env, and run ./pre-inst-env guix lint also
<Swedneck>do i need to worry about keeping the git repo up to date with upstream?
<pkill-9[m]>as long as it's fairly up to date, the patch will still work even if it was made with a different commit of guix
<Swedneck>alright so maybe i should run a `git pull` before editing it
<pkill-9[m]>i recommend working on a branch, then when you want to submit the patch, commit the change to the branch and run `git format-patch -1`, which generates a patch of the latest commit, and then submit that
<apteryx>do we still have to return #t for phases?
<apteryx>I keep wondering why we still do this and when we can stop ;-)
<pkill-9[m]>the patch is output as a file in the wokring directory called 001-something-something-something.patch (or .diff, can't remember)
<rekado>there are slides and the paper on code staging
<apteryx>rekado: I thought the grand scheme of things was to convert from a return-status based error control to a exception based error control? In this scenario, if no phase raised an exception, then it implicitly means a pass.
<apteryx>I think I remember now what Mark had said about it: until every phase everywhere have been migrated to use exceptions, we must return #t to ensure that those old fashion phases still do pass... or something along that.
<apteryx>I guess when every system*/system calls have been converted to invoke, this goal will have been achieved
<demotri>rekado: Ah, thanks. You released an hour ago :-)
<civodul>'guix lint' detects the "wrong" GitHub URLs now
<demotri>Puh, the most confusing thing is this: In both cases, you can click the tab "Releases", in both cases they show the autogenerated files and only if someone manually uploaded (again) the source code, it is extra shown with a box icon in front.