<katco>lfam: so, am i reading your statement correctly? could i place each module in its own output, and then the dependencies wouldn't be brought in unless you install that output? <lfam>katco: It depends on if the files in each output contain strings that reference the other outputs. Sometimes this is easy, sometimes it's not worth the effort <lfam>The presence of the strings will cause the outputs they name to be considered as run-time dependencies of the desired output, and thus downloaded along with it <lfam>katco: I don't know if they have this package or not, but it can be useful to look up what nixpkgs does in cases like this, which are really specific to the Nix/Guix paradigm <lfam>Sometimes, there is even a long Nix mailing list discussion from 10 years ago <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. <mbakke>katco: right, compiling syslog N times is no good :-) the union approach will work with outputs too <mbakke>apteryx: happy to be your rubber duck! :) <katco>mbakke: do i have that right? small module packages would mean compiling it N times? <mbakke>katco: it depends on the build system, ideally each module would be able to use a pre-built rsyslog <apteryx>mbakke: bah, that still didn't work :-/ <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? <mbakke>apteryx: maybe it's easier to (replace 'check (lambda _ (invoke "ctest" "--args"))) ? <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? <ngz>butterypancake: isn't is transmission-daemon ? <butterypancake>it didn't add that to my path. After reading the desktop file it installed, it really looks like the cli should be installed <ik1>Sorry for spaming once again. I retry install and everything is good. The problem was probably my cat who disconnected ethernet cable). Thanks everybody. <mbakke>katco: looking closer, it seems like rsyslog only has a handful of modules, and they must be built along with the main package (enabled in the configure script) <mbakke>katco: so I think multiple outputs makes a lot of sense for rsyslog <katco>mbakke: i just hope multiple outputs will split the graph so users aren't always having to bring along all databases for all modules <apteryx>mbakke: that almost worked, but it seems the makefile does some setup to find binaries <mbakke>katco: great that you consider output sizes :-) <mbakke>ik1: smart cat, good way to get your attention <katco>i am a user of `guix pack` so i have a great interest in bringing them down. <katco>i was delighted when mariadb was split because i build container images/packs with its client only. <mbakke>katco: you'll probably enjoy the reduced sizes of util-linux, gtk+ and llvm from the impending core-updates merge too <katco>nice! i hope that work is ongoing and we set up some sort of metric on median size to see if it creeps up <mbakke>katco: tracking sizes in Guix sounds like a great idea, I think cbaines' Guix Data Service already has everything needed <katco>like many, i wish there were more time in the day :| i'd love to contribute to that. <cbaines>yeah, the narinfo data is already there, just need a way to display that alongside the different outputs for a package <butterypancake>is there a way to few and manage global packages? I had gnome installed initially but I don't use it anymore <bav[m]>system packages are managed via the operating-system configuration <rekado_>two hours passed since I started “guix gc -C0” for the night <rekado_>it’s still at “finding garbage collector roots...” <jfred[m]>it looks like geiser may be trying to load modules from my profile rather than my local guix checkout ***wxie1 is now known as wxie
<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 <usney>What are the things I need to do after I run the installation script? <usney>I did guix pull and then installed ungoogled-chromium and it crashes and doesn't work this is the first program with guix that I ran into this issue. <usney>I think it might be something I forgot to install? <bav[m]>usney: which crashes? ungoogle-chromium or guix? <usney>ungoogle-chromium I'll pastebin the output <usney>I am using it on a foreign distro by the way <usney>I never had this happened before all the other times I have used it <usney>it is complaining about not being able to sandbox or something? bav[m] <usney>I know what sandboxing is it is a security feature <usney>maybe they forgot to compile it for that feature? <bav[m]>usney: do you have user namespaces enabled on your system? <usney>you think I could not be a part of the guix group or something? <bav[m]>I don't think that would be an issue <usney>you mean user namespaces for the sandbox containers for chromium to be able to use them? bav[m] <bav[m]>right, I assume that's what chromium tries to use <bav[m]>but did you read the mentioned doc about using a SUID sandbox helper? <usney>I'll look at that tomorrow I'll keep that in my notes to do. <usney>I need to be at work tomorrow in the morning. <bav[m]>I've not used guix on a foreign distro, so not sure if the suid helper works <usney>I will document all this for solving my issue tomorrow <usney>sorry for being lazy I could have look that up in the error log I was just looking for a fast fix since I need to go to sleep soon. <usney>but I help troubleshoot other users problems too sometimes <usney>bav[m] this doesn't look good <usney>I don't understand what they need that feature intel has hardware monitoring for years <usney>looks like more of a privacy issue right there <srandom>I defined a package that uses the source code of the git repository. How to calculate (sha256 (base32 "xxxxxxxxxxxxxxxxxxxx"))? <srandom>guix download does not seem to be used in git repositories <usney>you can use the sha256 or base32 package to make those numbers <usney>just make sure you use the option to create and not check the file <usney>sha256sum is probably what it is called <bav[m]>or `guix hash -rx /directory/of/git/clone` <usney>not sure about the program for base32 <usney>yup that is faster so I'd recommend that way that bav[m] said <usney>Gnu/Linux has many ways to solve the same problem <bav[m]>srandom: just make sure the git clone is checked out to the proper commit/tag beforehand <ubuntuxp>Is there a particular reason why gdm doesn't use wayland? <htgoebel1>civodul asked me to but some topic on the wishlist. How do I? <kmicu>Hi ubuntuxp: GDM is a login manager only. Iirc there’s no official support for Wayland on Guix System yet hence GDM starts Xorg like any other login manager in Guix System. <htgoebel1>civodul: You asked me to change bug#41093 into a wishlist item. Where do I send this to? <efraim>I killed guile3.0-gnutls on powerpc after 25 hours :/ <efraim>didn't think it would take that long *janneke is building linux .. <janneke>a hurd vm is (still) built inside a linux-qemu-vm <janneke>as soon as that works perfectly, mothacehe will help us stop doing that ;-) <mothacehe>heh I hope it's not that explosive anymore because I pushed wip-disk-image to master a few days ago :) <mothacehe>I'm working a race condition in Shepherd, but that's next on my list! *htgoebel1 still wants a bug interface which does not require expert knowledge to use <janneke>mothacehe: you did! \o/ ... oh, am i soo deep into hurd that i missed that <janneke>mothacehe: so what's missing then for hurd next to grub-non-efi? <mothacehe>janneke: Besides grub-non-efi, I hope its just some plumbing <mothacehe>Did you find the issue with hurd being not cross compiled? <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 <efraim>well, the uvesafb service should be fixed soon on non-intel-linux architectures soon <rekado_>I restarted guix-daemon and reran guix gc -C0 <janneke>first, i thought i needed to do something like (file-append (let-system system hurd) "/etc/login") <rekado_>8 hours ago. It has finished since then. <efraim>I might need a new goto phrase for non i686 and x86_64 architectures than non-Intel <janneke>but i think the idea is now that we can delay expansion, or wrap it <civodul>mothacehe: oh nice, i had completely overlooked your replies re wip-disk-image! <rekado_>so now is a good time to disable deduplication, no? <civodul>so the deleting-unused-links phase went faster this time? <efraim>would it help to put /gnu/store/.links on its own storage? <rekado_>would that even work? These are hardlinks <cbaines>it's also the biggest bit of the store <rekado_>I don’t know what went wrong before, but my lizard brain says that restarting the daemon helped <civodul>rekado_: it's a tradeoff: if we disable deduplication, GC is faster, but it needs to run more often (maybe very frequently or with a higher threshold) <efraim>maybe? I don't know, I'm don't know enough about it <cbaines>there are a few issues, but I think relying on substitutes more, rather than keeping everything in the store is a way to avoid having to have such a large store <civodul>cbaines: having a separate long-term storage you mean? <janneke>mothacehe: iow, the hacks i had using (with-parameters ..) are all fubar; gexps will "do the right thing" if we let them, is the idea <rekado_>cbaines: I don’t understand. Do you mean keeping the cache but not having things in /gnu/store? <rekado_>there is duplication now because the guix publish cache is also very large <janneke>i still suspect operating-system-derivation or its compiler <efraim>what if the nginx cache was on the front-facing node and ran GC often and the head build node just built stuff and fed the cache machine <efraim>I guess my idea depends on how much space the nginx cache takes up and how much space guix-publish uses and if it uses more space than just having it available from that machine's local store <cbaines>You trade off file level deduplication in the store plus all the tooling like guix gc, for compressed nars without that deduplication <rekado_>cbaines: and the build nodes can fetch substitutes from the coordinator node to get the prerequisites? <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 <mothacehe>Ok, I did some dirty fixes in (guix gexp) to have a bunch of procedures such as "file-append" to use (current-target-system), and get the target in monadic context. <rekado_>but … will the head node become swamped with uncompressing nars? <rekado_>offloading currently requires sending stuff to the build nodes <civodul>right, so what works for build-coordinator doesn't work well for offload <civodul>mothacehe, janneke: file-append-compiler (for instance) is explicitly passed the system & target, so that should be correct, no? <mothacehe>civodul: that's what I thought but janneke gets the wrong target value (#f) with this one. <janneke>(%current-target-system) is #f when we call (file-append ...) ...but that should never happen, right? <janneke>so, the client/caller of this code is wrong <janneke>...which "happens" while lowering operating-system-derivation <janneke>but...i'm losing the trail from there... <inwefnow>Is there any special reason why Riot Desktop (Matrix client) is not in the repos? Or is it just not packaged yet? <civodul>janneke: did you try changing #~#$profile (yes!) to just profile <civodul>(that would still be a bug, but at least removing the extra gexp will clarify things) <janneke>civodul: no...i /did/ try changing ,(file-append to ,#~#$(file-append <rekado_>inwefnow: as with most free software not in Guix it probably just hasn’t been packaged yet. <civodul>janneke: normally one can add as many #~#$#~#$#~#$ as we want, which is really nice! <janneke>civodul: ...i don't observe any difference <janneke>i hoped/feared that #~#$ might be different from #~#+ ...but i have no idea :-| *civodul builds a wip-hurd-vm checkout *janneke has terrible timing but goes afk for a bit -- brb! *janneke removes hurd-file-systems-service-type hack <janneke>now to test the new hurd-getty service instead of the "runttys" service hack <civodul>janneke: i think i found it: in hurd-grub-configuration-file, there's #+hurd <civodul>there are conditionals and stuff above, but these are not guaranteed to be evaluated in the right dynamic extent <janneke>civodul: oh; yes mothacehe saw that too; but i believe this is a red herring <civodul>so just remove the "if (hurd-target?)" instances, use #$hurd, and everything should be fine <janneke>yes, i didn't want to do this yet, as the "guix build -f gnu/system/hurd.scm" depends on that <civodul>but you're deprecating that file anyway <civodul>i think there's no need to maintain both in parallel <rekado_>inwefnow: oh, if it’s using a lot of JavaScript it might be very difficult to package properly. <civodul>reepca: can you try "git fetch origin keyring" first? <rekado_>yeah, it’s Electron. That’s going to be terribly complicated. <reepca>civodul: did that, still getting the error <janneke>i'll make the change, but i'm "pretty sure" the problem comes from hurd-etc-service <inwefnow>rekado_ Ahh I see. Guess I will wait for the terminal client to reach feature parity :p <civodul>reepca: hmm i guess you need to have a local "keyring" branch tracking the remote one <civodul>janneke: for me, #+ -> #$ solves the problem, as in the non-cross hurd.drv disappears <civodul>from "guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl -n --no-grafts 2>&1|grep hurd.*\.drv" <civodul>not that the non-cross hurd.drv doesn't show up in "guix system build --target=i586-pc-gnu ..." because that one doesn't build grub.cfg <bricewge>reepca, civodul: I got the same error with the keyring yesterday. You need a the keyring branch in a git worktree <bricewge>Either this should be documented or fixed to not require an additional work-tree, I prefer the later. <reepca>well, I created the local branch in magit, then switched back to master, and now it's recompiling everything. ¯\_(ツ)_/¯ <janneke>civodul: pushed (i think however that this now introduces an extra error, that shadows the [hurd-etc]-service problem ... but i could be wrong) <janneke>oh, i just see "<civodul> janneke: for me, #+ -> #$ solves the problem ... etc" <wxie>civodul: I want to install a Chinese input method via ibus-rime, do you know how? <wxie>rekado_: yes, I have installed ibus and rime. <rekado_>GNOME integrates ibus, so the setup differs from what you would do otherwise <rekado_>I only used ibus-libpinyin so far, not ibus-rime <rekado_>frustratingly, ibus-setup seems to be broken right now <wxie>rekado_: Thanks. How did you install ibus-libpinyin for guix? <rekado_>wxie: in the Gnome settings for “Region & Language” can you add your input method there? <rekado_>(currently, my Chinese input method does *not* work, so I’m probably not the best guide here) <rekado_>so you can select it but switching to it has no effect? <wxie>I have no input method installed yet, so it will switch but no effect. <rekado_>when I add a Chinese input method I see three choices: Chinese (Intelligent Pinyin) — that’s provided by ibus-libpinyin, Chinese, and Hanyu Pinyin (altgr) <rekado_>I never used the other two; don’t know how they are supposed to work <wxie>rekado_: so I can just 'guix package -i ibus-libpinyin'? <rekado_>I have both ibus and ibus-libpinyin installed <rekado_>the former is installed for the “ibus” and “ibus-setup” commands <wxie>rekado_: I have another question. Have you installed aspell and its dictionaries? <rekado_>I see that ibus-engine-libpinyin is running, but frustratingly I don’t see any effect <rekado_>probably something wrong with the env vars <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 *janneke builds wip-hurd-vm with --no-grafts <rekado_>jonsger: I’m updating icedove to the latest release now and will push after that <jonsger>rekado_: nice. I built the last patch before it and running it since yesterday. No issues so far. Thanks for your work!!! <rekado_>I never ran it after I replaced the SVG in the about window. Does this look acceptable? <wxie>Hi, Is there anyone who installed aspell for guix? <bricewge>civodul: Perfect! Now it works as i taught it would have when first reading the documentation about it. <wxie>rekado_: Thanks. I will check and try it out. <civodul>bricewge: great, i'll push it shortly <mbakke>civodul: I think so! need a working Cuirass first though :-) <civodul>mbakke: ah yes, i'll just revert the commit and we'll reinstate it "later" <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 <mothacehe>civodul: I'm trying something like: (if (eq? (getpgid pid) shepherd-pgid) (kill pid) (kill (getpgid pid))) <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 *janneke finally built automake without grafts <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 <civodul>or (equivalently) have posix_spawn bindings, though posix_spawn doesn't help with setting up namespaces and all that <reepca>single-threaded can be done with #:parallelism 1, but the issue is that certain operations don't really have nonblocking versions, and for those you need additional threads to be blocked <civodul>what operations do you have in mind? custom input ports? <reepca>for starters, local file I/O operations in general on Linux. They never return EWOULDBLOCK. <civodul>ah but there's (ice-9 suspendable-ports) for that <janneke>...yay, tcl8.3 "someone" should remove some dependencies from our bootstrap <wingo>local file ops still never return EWOULDBLOCK <wingo>but i dunno how much that matters <civodul>wingo: with #:parallelism 1, Fibers doesn't create any extra threads? <reepca>there's also file locks. In theory it would be possible to use a non-blocking version, but it would amount to busy-waiting <civodul>you can retry later with exponential backoff maybe? <rekado_>because of this #:file-creation-mask problem I think I’ll have to reboot ci.guix.gnu.org <reepca>the daemon typically attempts non-blocking once, if it fails it prints a message about it and falls back to blocking <civodul>rekado_: i reverted that patch BTW, perhaps we can reconfigure again? <rekado_>civodul: ah, thanks. I’ll pull and reconfigure. <reepca>which isn't a problem for it because it has one process per worker, and blocking doesn't cause liveliness issues <civodul>right, and you're going for one process in total? <civodul>we'll need introspection RPCs, so we can provide facilities like "guix processes" <civodul>or even viewing the build queue, stuff like that <civodul>reepca: does that bug ring a bell to you, BTW? *rekado_ deployed a new version of mumi <reepca>civodul: it's not something I've noticed previously, no <rekado_>you may need to refresh your browser cache <rekado_>I rewrote the way email bodies are parsed, so now we can toggle the display of blocks of lines (e.g. to hide quotes, diffs, or “cut here” snippets) <rekado_>something’s wrong with the style for the search hints <rekado_>have you refreshed your browser cache? <mbakke>katco: I think some of those modules could go in the default output though, at least the ones referred by the default configuration and don't add much to the closure? <katco>can you clarify what you mean by "default configuration"? <mbakke>katco: I mean the rsyslog.conf which almost certainly does "ModLoad imuxsock" <mbakke>though maybe the Guix service would take care of installing the correct output union :-) <katco>i don't think that is a certainty at all. my personal config does not read in from a unix socket. <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 <wxie>civodul: hi, I am wondering if the package guile-dbd-mysql is available. I only find guile-dbd-sqlite3 and postgresql. <wxie>civodul: I don't know how. Is there a guide to do this? <rekado_>krusnus: the texlive importer has outlived its usefulness in my opinion. <rekado_>krusnus: to add glossaries I suggest looking at texlive.tlpdb to see what files are supposed to be included (and which are sources) and then to use simple-texlive-package to build it. <rekado_>wxie: yes! Do you prefer video or text? <rekado_>the one in the cookbook is more up-to-date <wxie>ok, I will check and do it. <krusnus>rekado_: Cool do you know find out more about "texlive.tlpdb" and "simple-texlive-package" because i dont know what either of those are :) <rekado_>krusnus: texlive.tlpdb is a plain text file that lists all TeX Live packages, their contents, description, etc. <rekado_>it is provided by the texlive-bin package <rekado_>simple-texlive-package is a procedure that generates a texlive package <rekado_>it’s used in gnu/packages/tex.scm, so there are a few examples for you to learn from <krusnus>rekado_: wow thanks i'll look into that! <bav[m]>yay for gcc 10! who's packaging it now? ;) <janneke>yay, has its bootstrap story improved yet? ;-) <reepca>hmm, y'know, if we changed our interface from call-with-container to eval-in-container we wouldn't even need any C code, just system*. <reepca>system* can be used with multiple threads, right? <reepca>oh wait, we need to use clone, don't we... <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 <mbakke>temporarily removing gnu/tests/install.scm from the gnu/local.mk allows me to compile, but re-adding it gives the same error <janneke>hmm, M-x texinfo-all-menus-update is not the meme we use (any more?) <janneke>civodul: finally...yes, i think wip-hurd-vm is OK now wrt hurd-grub-configuration-file <civodul>mbakke: could it be that there's a stale .go for that file somewhere? <civodul>i've seen that before, and i think that's what happens <janneke>civodul: yeah, the hurd-etc-service problem seems to remain; but better to update wip-hurd-vm first, maybe <janneke>while i was building with --no-grafts, doing my bit in warming the planet, i did manage to get a hurd-getty service going and remove the "runttys" service hack <janneke>i have removed most of "runsystem" and start the shepherd very early -- it does seem that guile needs pipes upon startup, so we still have a tiny bash script <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. <pkill9>guix substitutes are transfered as lzip i believe, so when there's a substitute available it will be quick to upgrade <lfam>I think the issue is that Blender never seems to be available as a substitute. You always have to build it for some reason <lfam>Mariadb seems to fail often <lfam>Although, it is available for commit 5af1108 (week old master) <lfam>So, it must not be what caused Blender to fail that time <cbaines>it's actually been building reliably on ci.guix.gnu.org <civodul>janneke: yes, Guile needs pipe for its finalizer thread <cbaines>it's only the recent build that's canceled for some reason <lfam>It's not my experience. I almost always have to build it <lfam>Is there a way to see build logs from <data.guix.gnu.org>? <cbaines>Well that is just the build data, I don't know if it's built promptly, and it could be being built but for some reason a substitute isn't available <cbaines>lfam, there isn't an easy way, but there are some links to Cuirass, but there not very good <lfam>It loads some JSON which I'm not sure how to use <janneke>civodul: alright, then that makes sense. any ideas how to handle that best? it feels kind of silly to have a 4 line bash script to do "settrans -c /servers/socket/1 /hurd/pflocal" *janneke should push updated wip-hurd-vm -- but still testing the rebase <janneke># XXX This seems to be required for the Guile rc to run <rekado_>raghavgururajan: the problem is the bad let <rekado_>look closely at what’s right after “mime” <rekado_>you got this: ((mime (assoc-ref inputs "shared-mime-info") "/share/mime")) <rekado_>but a let binding can only have two: the name to be bound and the value <rekado_>you probably intended do write ((mime (string-append (assoc-ref inputs "shared-mime-info") "/share/mime"))) <rekado_>the difference between (list …) and `(…) on the other hand… <rekado_>the difference is that with ` (“quasiquote”) you can switch to “code mode” with , (“unquote”) <rekado_>so you can do `(hello ,(if personal? 'you 'world)) <rekado_>which is the same as '(hello you) when personal? is #t and '(hello world) if it’s #f <rekado_>one of your assoc-ref calls must be returning #f <rekado_>wrap them with pk to see which it is <rekado_>pk, pronounced “peek”, allows you to peek at a value <rekado_>(pk 12) is just 12, but it also prints 12 <rekado_>so (pk 'this (assoc-ref inputs "this")) will print “this” followed by the result of the assoc-ref call *raghavgururajan gonna test with pk <rekado_>but it will only return the last value <rekado_>so it doesn’t affect the meaning of your code <mbakke>was there a new version deployed recently? <rekado_>I reconfigured today, but I didn’t change the version. <cbaines>bayfront seems to be having issues with core-updates too <cbaines>it's not clear to me from the log why evaluation 5396 failed though <buffet>hey guix, im trying to update a package in guix, and i wanna check if everything works, so im running `./pre-inst-env guix build wlroots`, which leads to `no code for module (gcrypt hash)` <cbaines>buffet, sounds like your missing some Guile dependencies for Guix <cbaines>did you use guix environment to provide the dependencies? <buffet>im in the environment constructed by `guix environment guix --pure` <cbaines>what do you get if you run echo $GUILE_LOAD_PATH <mbakke>civodul: it happens inside a 'guix environment --container' that does not include guix or any other directories, and there are no .go files available :-/ bizarre stuff <mbakke>rekado_: I'll try restarting Cuirass again :/ <lfam>I'm not confident that `guix environment guix` provides (gcrypt hash) <lfam>At least, I had to install guile-gcrypt to make things work <rekado_>I suppose it depends on how old the Guix is that you use to run “guix environment guix” <lfam>buffet: Try installing `guile-gcrypt`, and then continue in the `guix environment guix` <buffet>cbaines, i just realized im not running the guix daemon from inside the environment. did that and now its downloading a whole bunch of things, gimme a minute <rekado_>the “guix” package has guile-gcrypt among its inputs <lfam>buffet: You don't need to run the daemon from inside the environment. It's not recommended <lfam>And, it doesn't affect these things <civodul>the kids just installed a "Minix" kart in Supertuxkart <cbaines>could be another animal commonly found in africa <civodul>hmm we need to start a working group <civodul>mbakke: could you "strace -f -o log make" to see what's the last loaded .go file before the failure? <sirmacik>civodul: dunno why elephant shrew came to mind <civodul>sirmacik: looks nice, and it can match our color theme :-) <buffet>lfam, that seems to work (i think) just gotta compile a shitton of stuff now. thanks <lfam>buffet: If you run the daemon "by hand" inside the environment, there are some arguments you need to set correctly <buffet>lfam, inside the env as in inside the guix environment or using ./pre-inst-env? <buffet>and i copied that exact command there (`sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild`) <lfam>I can't find the reference now but I think that you at least need to make sure you've built Guix so it can find /etc/guix/acl <lfam>The localstatedir argument to ./configure is always essential <lfam>I think you also need to set sysconfdir correctly but I don't know to what value for this use case <lfam>Right, you always should run ./configure with --localstatedir=/var, unless you have a reason not to <lfam>This is mentioned in the previous manual section, Building From Git <lfam>Does anyone know what sysconfdir should be set to? <lfam>So, I can confirm that I still have to install guile-gcrypt to use the pre-inst-env script, or else it fails to find (gcrypt hash) <NieDzejkob>when is %current-system set? Can I do something like (define-public my-package (let ((use-cross-binutils? (member (%current-system) ...))) (package ...)))? <cbaines>lfam, if you run guix environment --pure guix -- guile, can you (use-modules (gcrypt hash)) ? <NieDzejkob>lfam: I run ./pre-inst-env inside of guix environment guix (or guile3.0-guix, for that matter), and I don't need guile-gcrypt in my profile <lfam>Yes, it works in the environment. But I always thought that pre-inst-env should handle it <buffet>cbaines, assuming you mean me, yes i can <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>Go code, .go files, a match made in heaven! <cbaines>Maybe there could be a guix-pre-inst-env script that runs pre-inst-env with guix environment <cbaines>It would be slower, but provide a route out for people <lfam>So, it's supposed to work like this? I always thought it was a bug <lfam>Why don't I have to install the rest of Guix's dependencies to make pre-inst-env work? <cbaines>you probably do, maybe you just get an error about guile-gcrypt because that's the first one used <cbaines>some dependencies are actually optional as well <lfam>I don't have to install GnuTLS or guile-sqlite <rekado_>pre-inst-env is only meant to prefer the current directory over the installed Guix modules <buffet>so is it guix environment guix thats not getting the required dependencies? <cbaines>buffet, guix environment guix should be providing the required dependencies <buffet>im doing this on my laptop, everything takes a while <efraim>I got a hash mismatch for trezord source <lfam>Right, I remember that discussion now <mbakke>civodul: it looks 'git-predicate' poisons the Guile cache somehow? <mbakke>civodul: it compiles if I hack git-predicate to just return #f <raghavgururajan>rekado_ Got it! It was (("/sbin/ntfslabel" file) (string-append ntfs-3g file)). I missed to add ntfs-3g to inputs. <mbakke>civodul: the issue is probably highly localized, maybe we can merge regardless? <mbakke>lfam: if you have time, can you try to merge core-updates into master and running 'make'? *mbakke goes AFK for a few hours <civodul>mbakke: oh git-predicate; well, i guess we can merge <civodul>the git-predicate issue is probably not that bad <lfam>Does anyone know the option to make Git show the actual diff of a merge? *civodul shamefully doesn't know <lfam>Well the only conflict is a trivial license header thing <buffet>cbaines, lfam, getting the same error <cbaines>buffet, ok, no problem, so what command are you running? <cbaines>and what does echo $GUILE_LOAD_PATH say? *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` <buffet>also getting the error when inside `guix environment guix --ad-hoc guile-gcrypt` <cbaines>buffet, so what's your $GUILE_LOAD_PATH in the shell within guix environment guix ? <cbaines>buffet, Ok, so looking at your Guile load path, it looks to be mixing Guile 2 and 3 things, which I've found problomatic <cbaines>You can either use guix environment --pure guix, or just export GUILE_LOAD_PATH="" and export GUILE_LOAD_COMPILED_PATH="" prior to running guix environment guix <buffet>same error, path is /gnu/store/wbpg666qkxhdwayssaix7jln0fs624gz-profile/share/guile/site/2.2 <cbaines>buffet, OK, and what does guile --version say? <cbaines>so if you run guile, then try (use-modules (gcrypt hash)) that definately doesn't work? <buffet>./pre-inst-env guix build wlroots <cbaines>given that those lines are prefixed with substitute:, I think it's a process running in the environment of your other terminal that's failing <vagrantc>does ci.guix.gnu.org try to hold onto substitutes from v1.1.0 ? <buffet>cbaines, so should i run the daemon from inside `guix environment guix` after all? <buffet>this builds a shit ton of stuff, which doesnt seem incorrect at least <cbaines>vagrantc, data.guix.gnu.org only has revisions for commits that were pushed to the repository, so it's states the repository was in, rather than every commit <cbaines>vagrantc, right, I've had a look now. That commit isn't on the master branch, just the version-1.1.0 branch <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. <cbaines>raghavgururajan, why do you want that? <NieDzejkob>raghavgururajan: quick'n'dirty: add a (lambda _ #f) phase after the ones you're interested in, run the build with -K <cbaines>raghavgururajan, right, OK. What I normally do is cause the build to fail just after the time I want to inspect the state <cbaines>raghavgururajan, then run with --keep-failed <cbaines>I normally go for a phase that contains (error "Foo") <NieDzejkob>wouldn't the phases you're interested in run after unpack? <raghavgururajan>Will this phase as the last one? Because guix sometimes do phases in different order than specified in package definition. <raghavgururajan>OK, build failed correctly. Now, should I manually go to the specified /tmp dir or is there a command to get the patched source? <cbaines>raghavgururajan, I'd just go to the directory in /tmp that's given in the output <reepca>anyone else find that pulseaudio will sometimes detect an audio device but not create a sink? <raghavgururajan>Can I specify more than one directory for "with-directory-excursion"? Like. (with-directory-excursion "src" "data" ? <cbaines>raghavgururajan, I think (with-directory-excursion "src/data" would work, if I understand correctly <cbaines>You can only have one current directory <raghavgururajan>Btw, just in case, if I specify "src/ptk", would substiute* look for files in both src and it's subdir ptk? <cbaines>raghavgururajan, if I remember correctly, substitute* takes one file, and performs some substitutions <seasharp>Hey, any chance anyone has a package def for Gerbil scheme? if not, is there a package def I could refer to that bypasses everything but the unpack step in gnu-build-system? <Kimapr>anyone tried to run a vpn server under guix system? <Kimapr>after a few trials and errors, looking at the docs and code, i put this in my services list: <Kimapr>> (service openvpn-server-service-type <Kimapr>> (openvpn-server-configuration)) <Kimapr>and it seems to do the reconfiguration (still downloading the things needed) <cbaines>seasharp, I can't see a package for gerbil scheme, but I didn't look very hard. Regarding the build system, if you just want to do the unpack, maybe the trivial-build-system would be better <cbaines>seasharp, how is gerbil scheme built from source? <seasharp>cbaines, great question! I just unpack the tarball, cd to the ./src directory and run ./build.sh <cbaines>seasharp, I'd maybe start with the gnu-build-system, but delete the configure phase, and replace the build phase with something that does exactly that <seasharp>cbaines, Yup that's as far as I've gotten but I can't seem to disengage all the other steps. I can keep trying to figure it out, but I wondered if there was already a def I could refer to <cbaines>seasharp, what other phases are causing issues? <seasharp>cbaines, All the others, pretty much. Let me check I have the build logs somewhere.... <seasharp>cbaines, this is why I'm inclined to agree with you that I should use the trivial-build-system, but I thought it could only move files <cbaines>Quite a few packages use the gnu-build-system, but change the configure, build, check and install phases <cbaines>often you still need to do those things, so just replacing the phases often works <janneke>hmm, i think /hurd/ needs to exist...reading glibc <janneke>it looks like symlinking does not work without that <janneke>guess it makes some sense that the file system should work with any kernel <seasharp>cbaines, thanks for your help. I think I just need to find out how to skip the ret of the steps and replace `sh` with my distro (Fedora) version (or install sh on guix) <cbaines>seasharp, so the gnu-build-system has a patch-shebangs phase which should help with the /bin/sh issue <cbaines>seasharp, the other problem I see is that it's trying to run what it thinks is a bootstrap script, but it's actually a directory <cbaines>seasharp, the things you can do to fix these issues are: rather than adding a buildscript phase, replace the build phase <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. <pkill9>dikvj9x4jp7h3wdbfipz4zc257vzw3hd-qtquickcontrols2-5.12.7.lib.qt5.qml.QtQuick.Controls.Material'` <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 <mbakke>lfam: did the merge work for you? <lfam>mbakke: Yup! It built fine and I already had the build output for 'hello' <lfam>The other conflict was an easy license header thing <lfam>I mean, the only conflict <lfam>I'm trying `guix pull --url=/home/lfam/...` now <lfam>I expect it to work since I've been running some other systems on core-updates <lfam>Can you do it janneke? Or is something one of us can do easily? <lfam>What other checks do we need to perform? <janneke>lfam: i'm half joking, but sure i will do it <civodul>janneke: the cross-toolchain should be all fine? <civodul>speaking of which, should i take another look at wip-hurd-vm? <janneke>this=> ./pre-inst-env guix system vm-image --target=i586-pc-gnu gnu/system/examples/bare-hurd.tmpl -n --no-grafts 2>&1|grep hurd.*\.drv *janneke i may have missed some of civodul's cheap $$$ fixes? <raghavgururajan>mbakke: Thanks for the feedback regarding #40994. I am gonna work on your suggestions now and send a new patch-set. :-) *civodul has experimental relocation via ld.so for "guix pack -RR" <buffet>ok, so im back from earlier. checked my laptop and its still building. the store is at least 1200 files bigger than before, and it builds stuff like libMagick that doesnt seem releated at all <buffet>i really feel like this is not what i want <cbaines>buffet, are you using substitues from ci.guix.gnu.org ? <buffet>is that the "do you want to use prebuild binaries from the farm (yes/no)? thing during installation? <buffet>but this is master, so i dont know if theyre built yet <cbaines>Ok, so what did you ask Guix to build? <buffet>`./pre-inst-env guix build wlroots` <buffet>and i just realized it builds random stuff <cbaines>Perhaps try running guix build --no-grafts --dry-run wlroots and share what it outputs <buffet>i mean, unless guix defaults to some graphical stuff ofc <cbaines>buffet, grafts are a feature that tweak packages once they're built to apply security fixes or other changes <cbaines>disabling grafts makes it easier to predict what will be built <cbaines>buffet, I'm slightly doubtful that you're using substitutes. I can't imagine all of that needs to be built <cbaines>did you use the install script for Guix? <cbaines>are you running the guix-daemon through a system service, or in a terminal <cbaines>I know you said terminal earlier, but the install script usually sets up a system service <buffet>`sudo -E ./pre-inst-env guix-daemon --build-users-group=guixbuild` <buffet>its connecting to that, not to the system service <cbaines>buffet, right, so given you're not passing --substitute-urls to the guix-daemon, you're not using substitutes <buffet>how far behind master is the ci anyways? <cbaines>out of interest, how come you're running the guix-daemon in a termial? <buffet>yeah i just realized there is a webserver running <cbaines>buffet, right but the "Running Guix Before It Is Installed" doesn't apply, because you installed Guix? <civodul>janneke: now the "bad" hurd.drv has many derivers, whereas before it only had etc.drv <buffet>and the site for that pointed towards runningbeforeitsinstalled <cbaines>buffet, out of interest, what init system are you using? <cbaines>buffet, Ok, and what does sudo systemctl status guix-daemon.service say? <NieDzejkob>that page is just providing various examples of using ./pre-inst-env <NieDzejkob>you don't need to run guix-daemon in pre-inst-env when you want to work on a package <buffet>i stopped it before i ran the guix daemon <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 <buffet>alright, with the system daemon its like 10 derivations or so <cbaines>buffet, you're welcome, sorry you ended up on a bit of a bumpy path <buffet>i learned a bunch of stuff, and it kept me from procrastinating :p <buffet>alright nvm, build error: getting attributes of path /etc/services: no such file or directory <buffet>while applying grafts, lemme --no-graft <cbaines>grafts come after things have been built, so if that error is from the build of a package, I doubt disabling grafts will make a difference <cbaines>is that error from the build of a package, if so, which one? <buffet>after i bumped the version number <cbaines>maybe share the command and error on paste.debian.net <cbaines>buffet, hmm, I don't think I've ever seen that error <buffet>alright, so there is /usr/etc/services apparently <cbaines>I've got no idea where that message comes from... <buffet>turns out opensuse is trying to seperate config files done by the distro people and files relevant to the sysadmin, and therefore they move some stuff from /etc/ into /usr/etc/ <buffet>ok so it *seems* to work, but the meson version is too old now <buffet>suddendly i dont feel like going down this rabbit hole <buffet>is there a nice way to validate the checksums of a package without letting it fail and then copying it over? <cbaines>guix refresh -u can update checksums <cbaines>I normally use the approach you describe though <cbaines>I do use guix refresh where I can though <NieDzejkob>buffet: meson has been updated on core-updates, so you might see that the update is possible soon 