<katco>it appears as if they are pulling everything in
<mbakke>katco: another approach would be to have a procedure like 'define (rsyslog-module rsyslog-package name description)' to easily create small module packages and a corresponding 'rsyslog-module-union' procedure so users can create a union of the modules they want for use in the service
<apteryx>mbakke: I'm struggling to disable two tests (ctest). The generated Makefile does something like: test:\n\tctest ... $(ARGS). Testing interactively, export ARGS='--exclude-regex cli_export-latex' does the job. But a phase added before 'check that does "(setenv "ARGS" "--exclude-regex cli_export-latex")" doesn't.
<katco>mbakke: i thought about that, but then we'd be compiling rsyslog N times
<katco>mbakke: if it's true that dependencies can be managed via outputs by what strings are referenced, that would be ideal. build once, split into outputs, and the packager takes care of what's brought in.
<apteryx>ah, I know! I had to move the check phase after the install phase.
<butterypancake>what does the guix transmission package even install? It doesn't install the cli from what I can tell and I can't figure out how to start the daemon? also how does guix system do daemons?
<katco>mbakke: this is the `gnu-build-system`. i haven't yet worked on a package of this complexity. so if i do small module packages, they would rely on the complete package, and use its artifacts? is there precedent i can reference?
<jfred[m]>ahh, I think setting `guix-load-path` has done the trick
<jfred[m]>although I'm not entirely sure how, since I'm still switching to a repl with the generic geiser commands... maybe `guix-devel-mode` did something, or maybe that was a red herring and guile actually just finished compiling stuff over time :P
<apteryx>lfam: phew, I've just emailed the patch series for inkscape 1.0
<janneke>mothacehe: almost...when "hurd-etc-service" (a trivial, good example to help debugging it) does: (file-append hurd "/etc/login") that gexps "gets expanded" at the wrong time/in the wrong environment
<rekado_>well, currently we only have deduplication in the store
<cbaines>and you're providing substitutes anyway right
<mothacehe>janneke: ok! That's great. Not sure why "file-append" doesn't behave how we want.
<janneke>mothacehe: i think that we believe that it /does/ behave like we want...but where/when it gets expanded (%current-target-system) is #f
<rekado_>we have this huge cache a) that isn’t available before someone requests something (so it’s full of holes), b) that we can’t easily prune, and c) that duplicates what we already have in the store
<janneke>so the simple fix is: when cross-compiling, do not expand gexps when (%current-target-system) == #f
<cbaines>rekado_, it shouldn't be full of holes, as data.guix.gnu.org methodically requests everything
<cbaines>but it does duplicate what's in the store
<rekado_>if the store is pruned quickly and is kept pretty small then it doesn’t really matter that much if deduplication is enabled or not.
<civodul>cbaines, rekado_: we could have the daemon on berlin substitute from localhost, and adjust publish/cuirass TTLs accordingly
<reepca>civodul: not sure, can't quite find out how to apply it to test it (once the massive recompilation finishes). "git am" says "Patch format detection failed"and "git apply" says "error: corrupt patch at line 19".
<rekado_>one thing that’s unfortunately still true is that ibus embeds store file names in its cache and configuration files, so things can become broken (as in my case) after upgrades
<rekado_>you would then have to delete ~/.cache/ibus and ~/.config/ibus
<mbakke>oh, there is another bug on core-updates I haven't bothered fixing yet: running 'guix pull' will print a warning from (guix build emacs-build-system) that "(guix build utils) overrides core binding 'delete'".
<mbakke>as emacs-build-system imports (srfi srfi-1), I think we can hide the delete binding from (guix build utils)
<mothacehe>civodul: your bug report 41123 could be linked to the race condition I'm investigating during installer tests.
<mbakke>or maybe just import exactly what it needs from (guix build utils), /me looks
<mothacehe>civodul: I proposed a patch, that does not work at all :p I'm still investigating
<civodul>mbakke: yes, that's annoying, we should #:hide stuff and all
<mothacehe>civodul: a summary is that when stopping a process that has been forked but not yet execed, we now run (getpid the-process), which will be the one of the Shepherd , which is 0. Hence (kill 0 SIGTERM) kills everyone!
<mothacehe>Haha, I can sometimes reproduce it in Shepherd tests by running a for loop doing "herd restart test".
<krusnus>have any of you had any luck using latex on guix? For me the default packages fork fine when I've installed the texlive (although it's the 2018 version for some reason) but tlmgr doesnt work for me. i get the following error when using tlmgr https://paste.debian.net/1145468/
<civodul>mothacehe: i guess we could synchronize parent and child over a pipe
<civodul>or simply sanity-check the result of getpgid
<pkill9>anyoen kjnow what is causing this error when using (assoc-ref %build-inputs ..) in #:configure-flags argument?: error: %build-inputs: unbound variable
<mbakke>pkill9: perhaps you are doing that in an unquoted expression?
<mbakke>strangely, all the build systems warns about (guix build utils) overriding core binding `delete' when compiling Guix, but (guix build emacs-build-system) is the only one that shows up during 'compute-guix-derivation.drv'.
<mbakke>I guess we can deal with the others on 'staging'
<efraim>perhaps not as helpful as it could be, I use enlightenment and have en_US and he_IL setup through enlightenment
<pkill9>i want a desktop environment like retroarch
<wxie>rekado_, civodul: aspell is installed and works. Thank you.
<reepca>civodul: if we could guarantee that every thread was at a "safe point" when the fork occurred - for example, by using system-async-mark to interrupt all but the current thread for a duration - at the time that a fork occurred, would the child be in a workable state?
<civodul>reepca: technically, we would need to do that in C
<civodul>that's why wingo rewrote open-pipe in C some time ago, for instance
<civodul>we just can't use primitive-fork from a multi-threaded program, and Guile kindly warns you about that ;-)
<civodul>so what i'd suggest is to either force Fibers to use a single thread, but i don't remember if it's possible
<katco>i'm not sure how familiar you are with rsyslog (i'm not that familiar myself), but it is often used in log aggregation workloads where it is responsible for shunting logs. inputs and outputs can vary greatly depending on users' environments.
<mbakke>katco: I've used it for centralized logging using the network modules, but that is a while ago
<katco>are there any other modules you think should go in the default output?
<mbakke>katco: not sure, I think a Guix service could parse the configuration and automatically include the necessary modules, so maybe we don't need any by default
<mbakke>the other approach is to include most of the modules that do not carry extra dependencies
<katco>i do have a bias for closure size since i'd like to see guix more widely used for building container images and for embedded systems
<krusnus>everyone! i'm trying to install a latex package but tlmgr doesn't work, which i explained previously in this chat, but i stumbled upon guix import which seemed to be a solution to my problem but whenever i try to import through for example "guix import texlive glossaries" i get error: https://paste.debian.net/1145489/ I thinking it may have somethi
<krusnus>ng to to with the archive option but i cant for the life of me understand what i'm supposed to pass to "--archive=" as the directory for this particular package is macros/latex/contrib/glossaries
<reepca>... and I just realized system* would wait, which wouldn't be desirable. Agh. I should stay quiet when I'm this tired
<civodul>we could use unshare, but i think it'd be a little more tedious
<civodul>because we would need to fork, unshare in the child, and somehow notify the parent
<reepca>the rube-goldbergian process in my head right now is to use some safe guile built-in procedure to launch another guile process with an expression passed via -c, which calls unshare, synchronizes with the parent as necessary, and finally evaluates whatever expression eval-in-container was passed
<mbakke>civodul: so I did a test merge, and get "error: failed to load 'gnu/tests/install.scm': No such file or directory" when running "make" (inside 'guix environment --container', after 'make clean-go')
<mbakke>loading the file in 'guix repl' shows that it tries to stat gnu/packages/patches/texlive-bin-luatex-poppler-compat.patch which does not exist
<mbakke>'grep -R --binary' shows that the only reference to that file is in .git
<gnutec>#Guix is the best. Now I change to Openshot instead Blender, have less tools but Blender take too long time to upgrade in Guix. Blender is a tar.xz package and Openshot is a tar.lz. The Openshot installation is really fast and the app has a amazing design for low hardware.
<raingloom>can we make git-fetch not clone entire submodules with all their history? it's rather wasteful right now.
<buffet>cbaines, honestly i feel like it failing there as well would be better
<cbaines>lfam, I'm not sure what can't find (gcrypt hash) if guile can
<lfam>cbaines: I'm saying that if I configure and build Guix, then leave the environment, pre-inst-env crashes when it can't find (gcrypt hash). Does that make sense?
<buffet>cbaines, guile from my system vs guile from ./pre-inst-env (potentially a newer version) maybe?
<cbaines>lfam, right, yeah, I don't think pre-inst-env captures the environment, or is meant to
<lfam>I'm not really sure what it does, but like the locales warnings, this is an issue that seems to trip everybody up
<lfam>And since Guix already depends on guile-gcrypt, I'd expect the GUILE_LOAD_PATH in pre-inst-env to handle it
<cbaines>buffet, the pre-inst-env script won't change anything about which version of Guile is available
<mbakke>civodul: uh, the only files that are opened before the failure are a bunch of git objects like '/home/marius/guix/.git/objects/e1/46498dee5fb4eab42b0734cbb07a5dcf43cb63'
<mbakke>./pre-inst-env guile -e '(use-modules (gnu tests install))' gives a rather interesting backtrace
<lfam>However, I also have to install guile-json and guile-git for various parts of Guix to work in this context, so I don't think the problems with guile-gcrypt are unique. Just more likely to be hit, since the hash module is used more
<cbaines>lfam, personally I use direnv with a .envrc file to automatically setup the environment when I ender the directory
*lfam started building the merge of core-updates into master
<buffet>cbaines, two terminals open, one has `sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild` running, the other is inside `guix environment guix` with `./pre-inst-env guix build wlroots`
<cbaines>(that instance of the Guix Data Service tracks all the branches, not just master)
<raghavgururajan>Folks! How do I get a *patched source* from guix? The command `./pre-inst-env guix build --source` gives me the vanilla source. I am looking for source that has been patched by phases `patch-source-shebangs and `patch-foo-bar; that are done after `unpack.
<pkill9>does anyone who has experience running a QML application on guix know how to fix this error?: `file:///gnu/store/dikvj9x4jp7h3wdbfipz4zc257vzw3hd-qtquickcontrols2-5.12.7/lib/qt5/qml/QtQuick/Controls.2/Material/qmldir:-1 plugin cannot be loaded for module ".gnu.store.dikvj9x4jp7h3wdbfipz4zc257vzw3hd-qtquickcontrols2-5.12.7.lib.qt5.qml.QtQuick.Controls.Material": Module namespace 'QtQuick.Controls.Material' does not match import URI '.gnu.store.
<seasharp>cbaines, ah right I'd forgotten about the patch-shebangs phase. Good tip. There's no bootstrap script so I definitely need to delete that phase for sure
<seasharp>cbaines, I believe the build step is what I replaced the buildscript with, but I'll have to make sure. I believe I'll need to delete most of the other phases aside from 'make install', though I'm not even sure if there's an install phase defined...
<seasharp>cbaines, anyways, all of the info youve given me is super helpful so thank you :)
<cbaines>seasharp, if you're unsure, I'm happy to take a look at your package definition
<seasharp>cbaines, that would be great! I'm so super green at this it's totally a trial and error process interlaced with goober-eyed gawks at the docs
<seasharp>(though I should finish my dayjob first ^-^' , so let me get back to you)
<cbaines>the reason I mentioned about replacing the build phase is that it looks like your buildscript phase is running earlier than the build phase would
<seasharp>cbaines, oh I see. I'll need to confirm I'm using the proc I think I am , then
<buffet>so how to check if everything is working then?
<cbaines>buffet, yeah, if you have some links to the documentation that set you down the course of trying to run the guix-daemon from a terminal, that would be useful. It would be good to try make it better.
<cbaines>buffet, what I'd suggest at this point is stopping guix-daemon in the terminal, and starting the systemd service
<cbaines>The installer will have configured the systemd service to use substitutes I believe