Hi,
Let me share my minimalist workflow before others tell you how to do
more complex things.
On 2025-09-15 14:08, devmsv wrote:
- Do Guix developers just hack in ~/src/guix, add their own
packages/updates, and commit them later? in this case:
I do have checkout with upstream Guix, and I keep it up to date and
every time anything is broken for me I fix it there, commit and push (if
you don't have commit access you could make a pull request instead).
That way it encourages me to keep fixing things that I encounter.
- How do they deal with channel authentication, merges, and rebasing
with Guix’s master branch?
The trick is I DON'T use that as my real guix checkout and I don't add
anything there that I'm not pushing to upstream.
I have a separate channel for my stuff:
https://git.elenq.tech/guix-packages/tree/
It's not very clean but I can use that for my stuff. In my channels file
I have a reference to that one, and also nonguix for some drivers.
I don't even use guix home. :)
- Is there anything like git bisect but for guix channel? so I can get
what commit (in guix) broke my channel and know how to fix it.
You can `guix time-machine` (for guix itself) for this with `git bisect`
(for channel code)... But it's a little bit tricky. It's easier to go
read which dependencies of the packages changed and fix on top of that.
I'm very intuition oriented in my debugging so this might not be good
advice.
- How to deal with broken package builds? They are catched by the CI
system: should be report them? why doesn't guix maintain a develop
branch and use master for changes that pass CI?
Hm!
I'm not sure about how the CI works, but when a build fails I'd say its
not cached. So every further commit on top would trigger the build again
properly.
Any tips or suggestions would be greatly appreciated because I’m stuck
trying to maintain my workflow without constantly running into problems
after updating Guix.
It depends a lot in the way you work. My packages are rarely broken, and
I try to upstream patches every time that happens.
My setup is also extremely minimal, and don't mind having outdated software.
If you update often, guix rollback is there to help you keep a
consistent system. About Emacs I don't know, because I don't use it.
* CONTEXT
I've been using Guix for 3 years now, I really like it, but every time I
try to update, some package I use does not build or some API change and
my custom channel stops working. I mainly use Emacs, EXWM, Firefox,
KDEConnect, and LibreOffice.
My own channel: consists of custom Emacs builds (from master), some
(emacs and not emacs) packages not in guix and a procedure to built
emacs packages with custom emacs versions. A few weeks ditched it
because couldn’t fix my channel with new changes in guix. Now using
gs-101/emacs-master and the built-in Emacs package manager with
package-vc-install.
I am dissapointed for not being able to use guix, but also (now) I don't
see the for Emacs because with use-package and :vc I can even share my
Emacs config with non Guix systems without problems.
At this point I’m even considering switching to another distro for my
desktop (I don’t have this many problems on servers, I don't do anything
special there and have automatic upgrades). *But I’m wondering... I’m
missing something in the development process or are my skils are not
enough for Guix*.
Thanks in advance!
Hope this helps a little.
Probably people are going to share better ways to deal with your own
guix system, putting your changes on top of guix and using a local guix
checkout for your running system and so on. I find that a little bit
more difficult but it's also possible and that might help you to keep
your code consistent with Guix itself.
I hope this thread triggers more people sharing their approach because
I'm sure it's going to be interesting for all.
Best,
Ekaitz