IRC channel logs
2025-07-02.log
back to list of logs
<ngz>noe: I have to recompile the whole Guix repository to test this. So, IIUC, once you have integrated the PR into your own repo, merging the changes is the same as before the move to Codeberg? <noe>Yes, you can consider this step similar to git am, the only difference being the commands codeberg gives you make a new branch, so you have to rebase the commits back on master. <noe>Or you could only do the fetch command and cherry-pick or other git stuff <ieure>ngz, I usually just check out a branch for the PR and build that instead of master. <ieure>ngz, Add this to the .git/config of your guix clone: fetch = +refs/pull/*/head:refs/remotes/origin/pr/* <ieure>ngz, Then `git remote update origin && git checkout -b work origin/pr/1234' <ngz>I have fetch = +refs/heads/*:refs/remotes/origin/* <ieure>Yes, that's standard, put the line I have underneath it. <ieure>There's also a `git config' incantation that will edit the file for you, but I can never remember it. <ieure>If you think the PR is out of date, after you've checked out a branch for it, you can `git rebase origin/master'. <ngz>OK I have now two fetch values in [remote "origin"] section. <ngz>ieure: And is there a simple way to push the built PR upstream? Or you just rebase work onto master, then merge them and push master? <ngz>OK. I think I kinda managed to push my first commit since the big switch. <ngz>ieure, noe: Thanks for the help. <spiderbit>Well I kind of did it, I am just to stupid to search the right variable now, but I can load dbus and swank <ieure>ngz, Yep, rebase the PR branch onto origin/master, ff merge that into your local master, push. <spiderbit>yes that is set: sb-sys::*sbcl-homedir-pathname* <spiderbit>searched the sbcl path cut of 9 chars added /lib/sbcl/ and set it to that... stupid solution but works... <spiderbit>hmm it seems that if I replace or something a build phase that it then not takes the other phases from the original package... so I have to copy them all into my variation <ieure>spiderbit, You're surprised that replacing something replaces it? <spiderbit>I need to copy all phases otherwise it does not do the other stuff <ieure>You do not. You're probably modifying %standard-phases instead of the package's phases. <spiderbit>I just want to modify 1 phase... and if I am very surprised or not is not so important I just don't get very clever after reading doku about it... <ieure>Dunno what you're saying. Share the package definition if you'd like help. <spiderbit>yes the stumpwm package also modifies standard-phases <spiderbit>I want to get rid of the install manual and create-desktop-ifle because they are just copies of the original package <spiderbit>And sorry for the indentation... have no good setup here for scheme <ieure>spiderbit, Right, yeah, you're modifying %standard-phases. You need to modify the phases of the package you're inheriting from. <ieure>(modify-phases (assoc-ref (package-arguments stumpwm) #:phases) ...) <spiderbit>so this is not good documented I guess no examples or anything showing that... just general Scheme skill... <ieure>spiderbit, Actually (arguments (substitute-keyword-arguments (package-arguments stumpwm) ((#:phases phases) #~(modify-phases phases ...)))) <ieure>spiderbit, There is a ton of prior art for this in Guix, `grep -r inherit gnu/packages'. <spiderbit>ieure so instead of ... directly (add-after...) <ieure>modify-phases works the same, but it's modifying a different thing. <ieure>spiderbit, Looks basically right to me, try it out. <ieure>spiderbit, You might need to ungexp phases. <spiderbit>error: substitute-keyword-arguments: unbound variable <ieure>spiderbit, It's in (guix utils). <spiderbit>ieure ok try it again... have to more or less do it in system that takes longer, to make it happen I put it in a seperate package so I could run faster guix build... <ieure>spiderbit, Yeah that's the ungexping I mentioned. <ieure>spiderbit, See `(guix)G-Expressions'. But tl;dr change phases to #$phases <ieure>spiderbit, Have you done any Lisp programming before this? <ieure>Okay. You've used quasiquotes? (let ((foo "thing")) `(bar ,foo)) ? <spiderbit>wrote a few things in elpa so not just config editing <spiderbit>at least one package is in melpa don't remember if there are others... <ieure>Okay. G-Expressions ("gexps") are like quasiquotes, but for sending sexps between package definitions and the build daemon. <ieure>#~ is like `, and #$ is like , <ieure>That is the tl;dr. But see the manual chapter I referenced for more. <ieure>So rather than unquoting a quasiquoted form, you ungexp a gexp form. <ieure>To pull stuff from the lexical scope the gexp is defined in, into the gexp itself. Because the gexp is evaluated by the build daemon. <spiderbit>I do all this fixing here only because I want to hack on stumpwm that was the original goal, sure I want to be also a bit better in guix in general switched here because I have a chance and got crazy over nixos language... sorry, but I done a few hours now and my brainpower (after hot day without AC) is limited :D <spiderbit>I hoped this is more straight forward and better documented / easier... <spiderbit>but well I learned a lot... still about guix today... <spiderbit>ieure for inputs it's easier you just do: (inputs (modify-inputs <spiderbit> (package-inputs stumpwm) and you can add your stuff... <spiderbit>ieure well thanks anyway but I think it's to much for me today and it works... so I let it be... <tusharhero>so I have been trying to get my ntfs dynamic mapped devices to mount as rw: https://bpa.st/EJDA, but to avail. The generated fstab looks like this: https://bpa.st/7LAQ, and the current mtab looks like this: https://bpa.st/M2YQ. Removing the "rw" options leaves "default" as the fstab option, but it still doesn't mount as rw. I can umount it and remount it manuall to make it rw though. <efraim>I'm feeling a large overlap between what I imagine to be part of the release team duties and team-core. I don't know if that's my bias being part of team-core or if it's actually there <futurile>jlicht: looks like no-one has touched that for a while! <jlicht>I'll have a look, see if I can something to work again :-) <z572>wingo: i think you need (add-to-list 'tramp-remote-path 'tramp-own-remote-path) on emacs <z572>see info:tramp#Remote programs <possiblyStupid>In procedure struct-vtable: Wrong type argument in position 1 (expecting struct): #<procedure keyboard-layout (name #:optional variant #:key model options)> <ieure>possiblyStupid, You're passing the `keyboard-layout' procedure to the `keyboard-layout' field of operating-system. <possiblyStupid>ieure: it was there by default (autogenerated when I installed the system), and it worked at the time <ieure>possiblyStupid, Yes, and then you changed it in a way which broke. <ieure>possiblyStupid, There's some magic in `operating-system' which binds `keyboard-layout' to the layout when you specify it, so you can reuse it. Since you aren't setting the (operating-system) anymore, it is not bound, so you get the thing that binding would have shadowed, the procedure. <ieure>I commented out the X stuff because it was causing problems for my specific config, uncomment it if you like. <ieure>(My config needs are uncommon, so this may not be an issue for you) <jlicht>ACTION is reminded of his "got a new error. Progress!" poster <PotentialUser-51>Hello all. Are there any official mirror for git.savannah.gnu.org, for use with guix pull? <ieure>PotentialUser-51, git.guix.gnu.org <ieure>PotentialUser-51, The repo has moved to Codeberg. git.guix.gnu.org points there, and if we move again, will point to the new location. <PotentialUser-51>Oh ok, thank you. Do I need to manually update the pointer, or should a guix pull do taht for me? <ieure>PotentialUser-51, Substitute servers haven't changed. <identity>PotentialUser-51: guix pull does that automatically, no changes on the front of substitute servers (why would there be?) <untrusem>I think someone was trying to package oniux for guix, what's the status on that? <ieure>untrusem, No idea, track down the issue or PR where that was happening? <untrusem>I think it was in this channel they messaged. I checked the logs webpage and tried searching for it but no success <kyoji_>Hey #guix, have a question. I am trying to compile emacs myself from git but am having some trouble with 'libggccjit'. <kyoji_>I am using a shell (guix shell --development emacs) to install dependencies, but manually installing 'libgccjit' with guix install libgccjit@11 (to match GCC version) <kyoji_>When running ./configure, everything goes well until it checks for libgccjit compatibility, where it fails to compile the test program <kyoji_>I've successfully compiled it on other systems so I know its something I'm doing wrong in guix <ieure>kyoji_, `guix shell -D emacs libgccjit'