<bdju>is there a way to check the /gnu/store hash thing of a package I have installed and then go find what files it has from there? because it just seems like the dragon binary from dragon-drop is gone and I wonder if there's one with another name
<Gooberpatrol66>what's an example of a package where the build directory is not in the root of the source tree?
<mange>I think anything using #:out-of-source? with the cmake build system does that. The awesome window manager, for instance.
<Luk6655>No, no raid. I'll keep my archive volume as lvm mirror (a slow spinning disc) and I plan btrfs for everything else. Perhaps with exception of /tmp. It seems to tick all the boxes (ability to shrink as well as grow online, transparent deduplication etc)
<apteryx>mbakke: I ended merging my GNOME changes before the staging merge, I got excited after testing it all :-). If the conflicts are too painful I can volunteer to merge master into staging to iron them out; let me know.
<mbakke>apteryx: nice! it would be great if you could handle the merge to staging and further to core-updates :-)
<mbakke>apteryx: in case you did not know, GNOME stopped using intltool years ago and just need gettext now
<apteryx>right, I saw this in your commits and made the switch where I spotted intltool usage; sometimes it was still needed by some package
<mbakke>the mutter upgrade still adds mutter-9 to runpath, that should probably be removed?
<mbakke>I noticed you added intltool to mutter, that's why I mentioned it :)
<apteryx>probably the configure option can be removed now that it's handled as a patch
<apteryx>oh. perhaps a merge conflict :-(. there was many of them, to the point I suspected git had a problem, but I realized they mostly were about adding #:meson meson-60, ah
<mbakke>heh, sorry about that, didn't expect that someone would be brave enough to upgrade to GNOME 42 on 'master' :-)
<podiki[m]>yeah, I do that sometimes too if needed (i often have some patch series in progress so try not to do anything too drastic; but yes stashes, etc.)
***maximed is now known as antipode
<abrenon>well yes, my next move would have been to try and clone anew somewhere else to see if my local version was somehow turned evil or if the problem was from the code itself
<abrenon>I was just unfortunately too shallow in my analyzis of git status: seeing nothing modified, I forgot about .gitignore and too quickly assumed it meant my repos was as good as a fresh clone
<efraim>for the translations I normally 'rm -r -- po doc; git checkout -- po doc' and then rerun configure
<tschilptschilp23>Hi! I'm just trying to write an r-package definition to be used with 'guix shell PACKAGES -f DEFINITION.scm' to look at a shiny-app. This here is the definition: http://paste.debian.net/1253746. However, when I run the command, I receive that one here: http://paste.debian.net/1253747. I've already compared to other r-package definitions and I can't really make out what's going on. Is guix somehow telling me, that I'm missing a
<tschilptschilp23>module? The package-section itself comes from 'guix import cran RcmdrMisc', I haven't really fiddled around with details here.
<zamfofex>Take the parentheses out of the package at the bottom.
<podiki[m]>unmatched-paren: well it should be built on staging :) if you just need 1.60
<abrenon>I found it very understandable when I needed to read that part of the doc last week, and I took it to mean "signed with the private component of an asymmetric key which public component has been authorized"
<gnucode>unmatched-paren sounds good. Would you say that sway 1.7 is much better than 1.6 ?
<zamfofex>Kind of a miscellaneous question, but does anyone know what’s the difference between “FAIL” and “XFAIL” in coreutils’ tests? I’m still trying to establish a substitute server, and coreutils’ tests failed, some of which are listed as “XFAIL”, and one that is listed as “FAIL”.
<trevdev>If I inherit some other package, is there a way to extend that package's modified build phases without having to copy-paste them and hope for the best later on?
<zamfofex>I think I figured out the issue! See: <https://logs.guix.gnu.org/hurd/2022-09-13.log#224914> Now, there are various ways to resolve it, I feel, and I’m not sure which is the most appropriate one. (1) Patch ‘glibc’ in Guix (or use a snippet). (2) Patch (or snippet) ‘coreutils’ in Guix. (3) Change Guix to include ‘/var/run/mtab’. (4) Send a patch to ‘glibc’. And (5) Send a patch to ‘coreutils’.
<trevdev>To elaborate, I have defined and built emacs-lsp-mode-with-plists which also needs to augment the build phases. I don't want to override the inherited augmentations, so I have copy-pasted them. This means if someone comes along to add some other augmentation for `emacs-lsp-mode` I will miss out on it if I do not catch it.
<zamfofex>Now, which of these do you think would make the most sense? 🤔
<jpoiret>trevdev: you'll want to use substitute-keyword-arguments and modify-phases
<jpoiret>there are a couple examples in the codebase
<trevdev>Thanks guys, I am already using `modify-phases`. I am also copy-pasting all of the inherited modified phases under the assumption that if I don't, they will be overwritten. Was that a bad assumption?
<zamfofex>It depends. You need to use ‘substitute-keyword-arguments’ like jpoiret instructed, alongside ‘package-arguments’ with the package you are inheriting.
<trevdev>Alright, I'll go for a ripgrep. Appreciate the help
<trevdev>emacs-treemacs-extra seems to have the example I am looking for. Nice!