<str1ngs>though (insert #\newline) should replicate that
<str1ngs>Formbi: does this work for you? (define-key global-map (kbd "C-m") (lambda _ (insert #\newline)))
<nckx>pkill9 <instagrafting>: A fork exploring that would be interesting to watch, but I don't think it would get very far. Different minor/patch versions of packages regularly add or remove dependencies and features, break compatibility with the previous dot release, and introduce new behaviour and bugs.
<nckx>Even identical VERSION fields can identify completely different package expressions with wildly different dependencies causing totally different build results. Things quickly become undebuggable. Yet another non-functional package manager--just the ebuilds are written in Guile now.
<cheim0>vits-test: yes you understood my comment :)
<vits-test>cheim0: Great. Now Emacs has pictures & Meta-sends-escape.
<apteryx>hmm, how do I run the daemon locally? sudo -E ./pre-inst-env guix-daemon --build-users-group guixbuild --substitute-urls='https://ci.guix.gnu.org' --max-jobs=4 works, but then it fails finding the signing keys because it looks under /usr/local: guix offload: error: getting status of `/usr/local/etc/guix/signing-key.sec': No such file or directory
<apteryx>I've reconfigured my checkout with ./configure --localstatedir=var --sysconfdir=/etc but still (I haven't ran make clean-go -- should I?).
<sneek>nckx, raghavgururajan says: Is bayfront back to being busy again? That is, the state where it was under routine build and gc, two months ago? I am stuck gc lock again. :(
<nckx>I know that's an old message but bayfront is completely idle (both CPU and I/O) at this time.
<nckx>GCs on CI/substitute servers (which deliberately keep huge stores) with spinning drives (to store said stores affordably) simply takes a long time. It's all done while holding an exclusive lock to keep the code simple and minimise the chance of bad things happening, but it's very inefficient.
<PurpleSym>xournalpp is crashing with the following error on a foreign distro: Gtk:ERROR:gtkiconhelper.c:494:ensure_surface_for_gicon: assertion failed (error == NULL): Icon 'image-missing' not present in theme Tango (gtk-icon-theme-error-quark, 0)
<roptat>I'm trying to get a new project approved at savannah that will contain our translations, so we don't need to give weblate access to our repositories directly, and it appears that the copyright in our po and pot files are not very consistent
<roptat>they're either copyrighted to you, the FSF or the authors of Guix
<bandali>i'm around btw, if y'all need to chat about that
<roptat>bandali suggested to use only "the authors of guix" and I agree, but I guess I need more opinions on that :)
<bandali>:-) yeah, i didn't look around for other non-FSF-copyrighted GNU packages on the translation project to see what the common practice is
<civodul>roptat: i'll reply by mail later, but i'm definitely not a copyright holder on the translations
<civodul>so perhaps it's a misconfiguration in our gettext machinery?
<bandali>either in ~/.exwm or in your regular emacs init file
<rupicapra[m4>Works fine in emacs init, I was having some issues. Weird. ¯\_(ツ)_/¯
<apteryx>I'm trying to get untruncated backtraces using a locally started daemon, but this doesn't seem to work: export COLUMNS=200; sudo -E COLUMNS=200 ./pre-inst-env guix-daemon --build [...]. What am I doing wrong?
<chaosmonk>hi, i am trying to get into guix packaging and need some help. if i define a single package in a file i can build it with "guix build -f /path/to/file.scm", but i can't figure out how to test an actual change to guix's source tree
<chaosmonk>i would expect "guix build -L /path/to/guix $PACKAGE" to work, but i get an error:
<chaosmonk>guix build: error: /gnu/store/jzhv2rjgppspvg9kgap7l0zn5p9xbdk4-tar-1.32 (system: i586-gnu) has no substitute
<chaosmonk>i would expect adding "--fallback" or "-s x86_64-linux" to avoid the need for that substitute, but i get the same error with either
<vits-test>chaosmonk: You need to `git clone` the guix repo, make changes to one of gnu/packages/NAME.scm, and test it.
<simendsjo>So `%shell` is #f rather than a string. Why is that?
<apteryx>lfam: OK. I thought it had to do with pango not supporting the ghostcripts fonts used as fallback, and that deja vu was selected as a replacement for ghostscript in our fontconfig default configuration.