IRC channel logs
2023-09-05.log
back to list of logs
<apteryx>rekado: I'd suggest to either 1) write a patch to avoid the cache or 2) write a patch to fix the cache invalidation, whichever is easiest <apteryx>loosing user phrases is less surprising than ibus not working :-) <piptown>is there a reason when writing bash scripts I have to use #!/usr/bin/env bash instead of #!/bin/bash? <michzappa2>As I've been (re)building my Guix System configuration 'guix search' output has broken at some point. I've tried different shells (fish, bash) and terminal emulators (GNOME Konsole, Kitty) with the same issue present. There's a strange format of non-rendered ASCII like "name: [[1mgcc-toolchain[[0m \n version: [[1m12.3.0[[0m". Anyone seen this before? <RavenJoa`>I have 2 packages/file-likes I need to substitute, a package and a set of scripts. If the package is the source and scripts a native-input, I get an error about the scripts not having permission for mkstemp. If I do a directory union of the two as the source, I get the same thing, but for the package this time. <RavenJoa`>I guess my question is, can I have 2 packages as _writable_ inputs which are copied to the output by copy-build-system? <mirai>nckx, podiki: so it's not well defined which package gets to rule over then? <mirai>pity, I wanted to give the zutils a try (zcat & co. but works regardless of the compression algo used) <RavenJoa`>The goal with this whole round-about thing is the user can provide program-files which are called by the apccontrol script. But the program-files should also be able to call back to the apccontrol script. This causes a bit of a circular issue when building. <viaken>I always preferred Zulip to Matrix anyway <xelxebar>Anyone else see this? I wonder what the deal is. <viaken>Looks fine for me. That's some impressive mojibake, too. I assume it's auto-selecting the wrong font somehow? <podiki>mirai: I believe it is consistent, I just forget which one "wins", first or last <podiki>mirai: the bug report I linked before has explicit examples to see <xelxebar>viaken: Right? Pre-rendered pages are fine, of course, and sites providing their own fonts seem okay. Looks like pages that select some default, local font are where the fun happens. <xelxebar>But, like, why would instantiating a new profile affect processes from a different profile at all? <xelxebar>I do have a ~/.config/fontconfig/fonts.conf file specced... <PaddyPatPat>Hello, if I've updated the M.2 wifi card from an Intel one to a ath9k compatible card (I believe: Qualcomm Atheros QCNFA344AH), is there something I should do to give the OS a kick to try to use the card? Restarting wasn't it. I also tried installing the ath9k-htc-firmware just in case but that wasn't it either. <PaddyPatPat>I didn't see anything obvious in the manual and I figured that if this card does indeed work with the ath9k drivers, that it would be picked up on restart. Maybe I've made a mistake. <PaddyPatPat>There is a line saying "ash10k_pci 0000:01:00.0: Failed to find firmware-N.bin (N between 2 and 6) from ath10k/QCA6174/hw3.0: -2" <PaddyPatPat>Hmm I should do this from the computer itself. I've made typos in there. <PaddyPatPat> 4.427998] intel_tcc_cooling: Programmable TCC Offset detected <PaddyPatPat>[ 4.436124] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC295: line_outs=1 (0x14/0x0/0x0/0x0/0x0) type:speaker <PaddyPatPat>[ 4.436129] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=0 (0x0/0x0/0x0/0x0/0x0) <PaddyPatPat>[ 4.436131] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x21/0x0/0x0/0x0/0x0) <PaddyPatPat>[ 4.436133] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0 <PaddyPatPat>[ 4.436135] snd_hda_codec_realtek hdaudioC0D0: inputs: <PaddyPatPat>[ 4.436136] snd_hda_codec_realtek hdaudioC0D0: Mic=0x19 <PaddyPatPat>I'm assuming that this is unrelated to the wifi though because of the messages surrounding it, even though it mentions "ath10k". <apteryx>for bluetooth sound, maybe, that card has bluetooth too <apteryx>where did you read this card uses ath9k? <PaddyPatPat>Or didn't understand the difference between ath9k and ath10k at the time. <PaddyPatPat>(which I still don't really understand but I now know that they are different). <PaddyPatPat>Yea. I should find a way to install an ath10k linux driver and see if that works. <apteryx>I gues they do, if it doesn't work in Guix <apteryx>usually you'll see a DEBLOBBED message from the linux-libre kernel if it happens. <ulfvonbe`>is there a way to include a literal entry in a search path specification? <ulfvonbe`>e.g. if a search path has a default value that includes the current working directory <ulfvonbe`>and said behavior should be preserved by default <ulfvonbe`>if you just include "." as an entry, the resulting search path will have <package-out>/. as an entry instead of just ".", which is less than helpful <vivien>ulfvonbe`, if you are packaging a program, you can wrap it to add "." to the search path <ulfvonbe`>yes, but then it's no longer possible to get the original behavior back if that's desired <ulfvonbe`>e.g. suppose there are some use cases where it's desirable to not search the current working directory, and setting the search path explicitly is how you do that <ulfvonbe`>this is, for example, how gforth's GFORTHPATH works <rekado>“guix deploy” from my x86_64 laptop to my aarch64 server only works without grafts. Grafts seem to always be built locally, and that fails because the system architecture is supposed to be aarch64. <rekado>it seems to me that grafts should be architecture agnostic <civodul>ah yes, grafts are marked as non-offloadable <janneke>dongcarl: trying to build bash-minimal for mingw (a dependency for guile), i'm getting <janneke>./config.h:361:19: error: two or more data types in declaration specifiers <janneke> 361 | #define socklen_t unsigned int <janneke>ACTION has already tried to revert to bash-5.1.8 (which builds on 0e9429544fd737079b9c1562de3beb48329350a9), but get the same error so it must be "something else that changed" <civodul>janneke: MinGW was upgraded recently, but that was a minor version bump IIRC? <janneke>civodul: yes, i looked at it but didn't attempt a fresh guile build; also it could have broken before that, really dunno... <janneke> /me is kinda rooting for spike121's grand guile mingw merge <efraim>civodul: I'm flying to India today but I'll ssh back to my desktop soon and test copying the 7.5 Gb file using guix archive soon <civodul>janneke: i disabled it soon after adding it, when i realized we didn’t have any i586-gnu worker <civodul>but! this week-end i added a cuirass-remote-worker instance on berlin for i586-gnu <civodul>(as we had discussed a couple of weeks ago) <janneke>civodul: oww, thanks for keeping hammering on that <civodul>i wish it’d move faster, but i seem to fail to get things done these days <janneke>ACTION has been trying to push a couple of releases out for over two months <janneke>sometimes progress is slow and you discover all sorts of things along the way <rekado>what is the proper way of managing Guix System containers as shepherd services? <rekado>in the swineherd extension I’ve been using “herd eval root” to create a new service for a Guix System container <rekado>the service comes with container-specific actions like “up”, “down”, “ip”, etc <rekado>when I want to destroy the service I do “herd unload root” <rekado>is this … gross? Or something we’d want in Shepherd proper? <rekado>would it be better to instead have a completely separate container manager? <cbaines>as soon as they hit a build that causes the childhurd to hang, that needs spotting manually and canceling, and the childhurd then needs restarting <civodul>i’ve been willing to add a service for “child systems”, similar to childhurds <civodul>my interest is in VMs here but it wouldn’t be too different i guess <civodul>actually, when would you recommend Guix System containers as opposed to mere services (or service containers)? <nikolar>how do i get the target triplet inside my package <nikolar>for example when built with guix build --target=... <cbaines>another hurd question, when is it useful to build linux-libre-headers for i586-gnu? <aitzkora>I need to modify the argument "-pX" of the patch command. Does anyone know the syntax on the guix side ? <aitzkora>I think i found It : (patch-flags '("-p0")) <nikolar>or a better question, why is %current-target-system always #f <NinjaTrappeur>guix pull is terribly slow on my x200 (~5 minutes to import a week worth of commits). I'm wondering what's the slow part. How would you profile this? <rekado>civodul: my use case is with Guix System containers on a foreign distribution <civodul>NinjaTrappeur: the slow part is “Computing Guix derivation”, which, well, computes a .drv from as little as possible to build the new Guix <civodul>the time is mostly spend in Guile’s macro expander <civodul>it’s pretty inconvenient to profile because you need to extract the script that does that <NinjaTrappeur>So, roughly speaking, you extracted this script (I assume manually? or do you have a trick?), then encapsulated it in a statprof call? <civodul>but yeah, it’s really a bummer that it this slow <cbaines>civodul, okay, I'll add it to my list of packages to remove i586-gnu from the supported systems <civodul>NinjaTrappeur: it’s been a while, but yeah you get its source file name, then you wrap it in ‘statprof’ or similar <civodul>if you’d like to look into it, i’m happy to provide guidance! <rekado>civodul: yes, I use Guix there, and I found it convenient to use shepherd to launch independent Guix System containers on the machine <rekado>I added an API server, so I can manage the containers through the backend of a web application <rekado>together these services form a platform to spawn Guix Systems on demand. <ekaitz>hi, how do you make a project install it's CMake modules that are searchable by include(...)? <vivien>bash cannot be built under mingw, that’s why cygwin exists <jpoiret>NinjaTrappeur: the main problem is that guix tries to use its own package definitions for guile/guile-ssh/etc. as dependencies for guix itself. The problem is that the package definitions are not yet compiled and thus take very long to load <jpoiret>you can reproduce this by setting %load-compiled-path to '() and doing (use-module (gnu packages guile)) <jpoiret>nikolar: %current-target-system is different from #f only when cross-compiling <nikolar>How do I get the target when building a cross compiler <nikolar>I can see that guix is passing --host to configure but TCC doesn't work like that <jpoiret>building a cross-compiler is more complicated <jpoiret>also, %current-target-system doesn't correspond to --target iirc <jpoiret>have you had a look at (gnu packages cross-base)? <janneke>vivien: i already knew that Guix is _amazing_, you'll be thrilled to learn it can even do things that are not possible, try: <janneke>guix time-machine --commit=0e9429544fd737079b9c1562de3beb48329350a9 -- build bash-minimal <janneke>hmm, i meant to say: that would be: guix time-machine --commit=0e9429544fd737079b9c1562de3beb48329350a9 -- build --target=x86_64-w64-mingw32 bash-minimal ... <janneke>possibly we didn't build bash-minimal as a dependency for guile before, in that case, where/how was the dependency introduced...hmmm <janneke>ACTION has been looking at / bisecting the wrong bug this morning, apparently <vivien>janneke, I know perl pulls bash to run system commands (even if on mingw, it should use cmd.exe) <janneke>vivien: good to know, i somehow remember we cross-built bash-minimmal on guix but as yet haven't find any proof of that <vivien>I’m not a perl expert, so I don’t know if packages that run system command expect to have cygwin or cmd.exe on windows <vivien>perl packages that run system commands* <janneke>vivien: i expect that running system using a non-posix shell will mostly give suprising results <vivien>But maybe perl packages have done a lot of work so that they can use cmd.exe <vivien>If we give them a posix shell it will confuse them a lot <nckx>mirai: The order's definitely not *well* defined. Committing to one consistent and documented order (right over left, bottom over top, bikes over sheds) everywhere probably wouldn't hurt anyone. <vivien>But maybe there are 2 clusters of perl packages, those windows-minded and those for posix. If that’s the case, we will mostly build posix-aware perl packages in guix, so we should have a posix shell. <vivien>I don’t know, I tried writing a bit of perl in my career once and it did not turn out well, so I’ll wait for an expert to shime in XD <apteryx>cbaines: it'd be nice if QA could tag Debbugs issues with a user tags like 'qa-ok' or 'qa-failed', to have the 'badges' info readily available from Emacs Debbugs <haider>For some reason, neovim seems to segfalt in a guix LHS container. <cbaines>apteryx, that should be possible, although it might require QA to start sending emails and I'm not sure how hard that'll be <civodul>comrades, anyone feels like writing/finding a tiny build log coloring script in JS that we could use in Cuirass & co.? <nikolar>i am working on tcc stuff we talked about <nikolar>and i have the crosscompiler working <nikolar>except for the part where it insists on linking with native libc <ekaitz>are you making the weird config.mk file or whatever it needs? <nikolar>it cleared some other linking errors <ekaitz>nikolar: i think it changed with recent version so be careful with that <nikolar>what exactly changed, the config format? <ekaitz>that's the "newish" way to do it <ekaitz>i don't remember if I shared that with you or the other <ekaitz>(i'm working in different versions) <nikolar>that looks like the one you showed me <ekaitz>great so that's more or less how it should be done <ekaitz>nikolar: now I have to go, but send me an email with what you managed to make and i'll try to help <ekaitz>my email is in guix code, just grep my name and you'll find it <ekaitz>nikolar: thanks for keeping me posted <RavenJoad>Can I have a package and a file-union of program-files as _writable_ inputs which are copied to the output by copy-build-system? <mirai>apteryx: I don't think debbugs understands arbitrary tags <apteryx>the user should be your own, or 'guix' if you want these user tags to be shared with others <apteryx>should we use the 'book-' variable prefixes for book, as proposed in #65669? <apteryx>for fonts we've had a -fonts *suffix* <apteryx>oh, that's a nice findig, I'm not sure I've ever seen that page <apteryx>mirai: it doesn't say how to use a specific user for setting the usertag though from that page. I think the 'Debbugs UG' manual has it <mirai>interestingly, it says “To use it you send a mail message to request at debbugs.gnu.org.” <mirai>so it's not the usual _control_ one <apteryx>oh, that's why my previous experiments failed, perhaps <mirai>which I think might imply that you can't add usertags to existing ones <apteryx>hm, info '(debbugs-ug Control Messages' doesn't say the server should be different though <mirai>but then “usertag 123456 help security” wouldn't make any sense <mirai>to be fair, the debbugs used by GNU isn't exactly aligned with upstream one so perhaps this was already ironed out <mirai>ACTION rebuilds the enblend-enfuse aberration of a definition but with doc split <euouae>Hello I tested guix and I got an error about my AMD Lucienne not being supported <civodul>euouae: hi! could you paste the error message and show us the command that you ran? <euouae>Hm... I'd have to restart and try to install again <civodul>euouae: oh maybe you’re talking about the Guix System installer, right? <euouae>civodul: is it related to non-free drivers? <civodul>euouae: yes, i suppose you saw the warning about unsupported hardware, which could be due to the lack of free drivers <civodul>(it could be a false positive in this case, i have no idea) <civodul>i guess that’s an amdgpu thing, i don’t know if it’s supposed to work with free software <civodul>i guess you could try installing and see how it goes <dthompson>like intel gpus, amd gpus have free drivers in the kernel but nonfree firmware <dthompson>haven't used an amd gpu myself but I think that's the case <dthompson>basically any modern gpu isn't going to work with linux-libre <nikolar>how do i get a path to a package in configure step <euouae>dthompson: including integrated gpus? <civodul>euouae: my recollection (if we’re talking about the same thing :-)) is that it’s a warning that doesn’t stop you from installing <euouae>civodul: I'll try again, but it'll take some time to re-download guix because I can't find it now <euouae>might've forgotten to copy it over when I moved to debian <dthompson>intel changed gpu architecture a few gens back <nikolar>how do i get a path from a package variable <nikolar>i am trying to pass a path to cross libc <nikolar>i have a variable which holds a package for glibc but i need to get the path to it so i can configure tcc <cbaines>when you declare inputs to a package, those inputs are available at build time, and you can lookup the filenames within the build script <cbaines>unfortunately, if it's documented, I can't find it <cbaines>I think the build systems usually pass the package inputs to as an alist to each of the build phases <RavenJoad>nikolar: (assoc-ref %build-inputs "package-name") <nikolar>i am trying to use it in #:configure-flags <cbaines>nikolar, it's useful to distinguish between an issue in the package definition, and in the build script <cbaines>I'm guessing in this case it's the package definition, maybe because some parts of the arguments should be a gexp (or quoted) <RavenJoad>%build-inputs should always be defined. You may need (arguments `(#:configure-flags (list (assoc-ref %build-inputs "apckage")))) <nckx>I'm going to poop on this parade and say that %build-inputs should be your last resort, and you almost never ever need the last resort. Use this-package-input, or (#:key inputs #:allow-other-keys) (search-input-file inputs "bin/foo"), etc. <nckx>Consider %build-inputs an undocumented implementation detail. <nckx>As opposed to most other things in Guix which are undocumented official API. <nckx>Does anyone run a Tor node on a Guix System? tor consistently uses 100% of a core after a while, forever. This for pushing 500K/s on average seems excessive. Also strange is that Nyx claims 0% CPU, but that could be a(nother) bug. <apteryx>softwareheritage.org is returning 500 errors when using 'guix lint' <jpoiret>i'm having a bit of a brainfart, #$(this-package-input ...) should take replacements into account, right? <janneke>if an inherited package means to substitute that input? <cbaines>jpoiret, replacements apply after you've built things, so they don't affect a package build script <jpoiret>package transformations i mean cbaines <janneke>ACTION reverted some package descriptions to using assoc-ref %build-inputs... <cbaines>I think for transformations, #$(this-package-input ...) should work fine <cbaines>although saying that, the implementation seems more complicated than I was imagining, so I'm unsure <RavenJoad>nckx: I did not know that. Is this-package-input available for setting #:configure-flags ? <nckx>search-input-file is not. <RavenJoad>Perfect! I will have to change xen to use this-package-input instead. That was where I got the %build-inputs from. <nckx>You don't have to, but it's always nice to have existing packages reflect the current style, so thanks! <mirai>it's an update for a package that I occasionally use when dealing with the “wtf is this package's license?” question <RavenJoad>Once I eventually figure out the runpaths issue, I can fix that and send xen back. I have narrowed down the validate-runpaths issue. That phase does not pick up the right paths for a python shared object. If I set LD_LIBRARY_PATH and check with ldd manually, everything comes back fine. <mirai>it's gotten some important fixes (wrt detection) so it's not just the regular “shiny new number from guix refresh” <janneke>nckx: in a personal archive; because a package has "sed" while its inheriting package replaces that with "sed-mingw"...but if the original (argumenst ...) section has #$(this->package-input "sed"), then boom <janneke>so yeah, iwbn if i new how to fix that properly <nckx><then boom> this-> was clearly NULL. <janneke>i could, of course, rewrite the whole phase that uses $this-input, but meh <janneke>i mean, copy it to the inheriting package and then change only that single line with sed -> sed-mingw <nckx>Well, it's a work-around after all. I doubt that this-package-things are *supposed* to work this way. <nckx>That said I haven't tested this exact case. <janneke>possibly the-way would be to merge sed-mingw into sed+, make switches/changes for the target architecture inline, and use sed+ in the initial package <nckx>Am I missing something when thinking this is ‘just’ an oversight in the current this-package-* implementation? Are you saying it's a fundamental limitation that requires modifying certain packages to work with it, forever? <janneke>that's a good question; it seems to me that the ("sed" ,sed) vs ("sed" ,sed-mingw) with associated assoc-ref %build-inputs "sed" indirection is gone <janneke>but i can easily imagine that civodul can think of another (a better?) way to play this <ekaitz>hi all, anyone experienced weird CROSS_C_INCLUDE_PATH behaviour in guix shell? <ekaitz>i just wrote to help-guix but as I was writing started remembering this happened before... <ekaitz>I can't find references in the ML though <ekaitz>basically arm-none-eabi-toolchain does not find stdlib.h which is in CROSS_C_INCLUDE_PATH <nckx>Anyway, I think we shouldn't encourage %build-inputs in new code, just because janneke has a well-documented love affair with weird xstuff and seeking out edge cases (that's a compliment, by the way :) <janneke>nckx: there's possibly (package-inputs this-package) that i could use to get rid of the old %build-inputs meme <apteryx>ungoogled-chromium-wayland@112.0.5615.165-1: probably vulnerable to CVE-2023-2459, CVE-2023-2460, CVE-2023-2462, CVE-2023-2464, CVE-2023-2465, CVE-2023-2466, CVE-2023-2468, CVE-2023-2721, CVE-2023-2723, CVE-2023-2724, CVE-2023-2725, CVE-2023-2726, CVE-2023-2929, CVE-2023-2930, CVE-2023-2931, CVE-2023-2932, CVE-2023-2933, CVE-2023-2934, CVE-2023-2935, CVE-2023-2936, CVE-2023-2937, CVE-2023-2938, <apteryx>CVE-2023-2940, CVE-2023-2941, CVE-2023-3079, CVE-2023-3214, CVE-2023-3215, CVE-2023-3216, CVE-2023-3217, CVE-2023-3420, CVE-2023-3421, CVE-2023-3422, CVE-2023-3598, CVE-2023-3727, CVE-2023-3728, CVE-2023-3730, CVE-2023-3732, CVE-2023-3733, CVE-2023-3734, CVE-2023-3735, CVE-2023-3737, CVE-2023-3738, CVE-2023-3740, CVE-2023-4068, CVE-2023-4069, CVE-2023-4070, CVE-2023-4071, CVE-2023-4072, <apteryx>CVE-2023-4074, CVE-2023-4075, CVE-2023-4076, CVE-2023-4077, CVE-2023-4078, CVE-2023-4349, CVE-2023-4351, CVE-2023-4352, CVE-2023-4353, CVE-2023-4354, CVE-2023-4355, CVE-2023-4356, CVE-2023-4357, CVE-2023-4358, CVE-2023-4360, CVE-2023-4362, CVE-2023-4364, CVE-2023-4365, CVE-2023-4366, CVE-2023-4367, CVE-2023-4368, CVE-2023-4427, CVE-2023-4428, CVE-2023-4429, CVE-2023-4430, CVE-2023-4431, CVE-2023-4572 <nckx>ACTION is reminded to upgrade their firefox package to fix CVE-2023-4573, CVE-2023-4574, CVE-2023-4575, CVE-2023-4576, CVE-2023-4577, CVE-2023-4578, CVE-2023-4579, CVE-2023-4580, CVE-2023-4581, CVE-2023-4582, CVE-2023-4583, CVE-2023-4584 and CVE-2023-4585. <acrow>Can others run nyxt (on guix system) without it crashing within a few seconds? <nckx>acrow: Anything I should be doing during those seconds? <acrow>tylerm: Thanks -- I guess it must be something local to me. <acrow>ncks: Not for me -- it just fails with a bad thread merge. <nckx>(Note that it will print *a lot* of warnings and even errors when running fine, e.g., ‘(WebKitWebProcess:2): GLib-GObject-CRITICAL **: 20:31:58.863: g_signal_connect_data: assertion 'G_TYPE_CHECK_INSTANCE (instance)' failed’) <nckx>Hm, my nyxt window has become uncloseable (Sway). <tylerm>I am running sway as well and it seems perfectly fine for me <nckx>I'm running it in a --pure shell and browsin' community.letsencrypt.org. <nckx>There being no hand cursor (probably due to the purity) is the only glitch I can spot. <apteryx>nckx: perhaps there's a 'banish' shortcut like in ratpoison <tylerm>Yep the --pure breaks the hand cursor for me as well <acrow>acrow: Looking at my local configs and telling nyxt '-I' did not help. Hmmm... <nckx>apteryx: I used pkill -9 but I do miss the drama that was the xkill death cursor. <acrow>Clearing out the contents of ~/.local/share/nyxt/ has resolved the issue. I still get lots of warnings -- about a bad locale among other things -- but it is working. <nckx>Hmm. If it is a Guix issue, maybe an embedded store file name? <acrow>nckx: I'm just suprised that nyxt doesn't seem to respect my GUIX_LOCPATH and trivial glibc-us-utf8-locales package. <acrow>nckx: I doubt it is a guix problem. More likely some aspect I don't properly understand. <unmatched-paren>I get 'encountered raw symbol in macro output in subform socket of (current-location-vector)' <nckx>ACTION just tried scheme@(guix-user)> (package (inherit (@ (gnu packages base) hello))) ; nothing fancy. <RavenJoad>I am also having issue with nyxt, but it might be related to missing GStreamer things. I cannot even load guix.gnu.org. <nckx>My Guix is also not the newest. <nckx>I'm on 9d2e6323775371ab0ccaec0fc1df3b50335c41ea. <nckx>unmatched-paren: So my silly example still fails? <acrow>unmatched-paren: guix.gnu.org doesn't render for me either. I did a fresh pull and update of all packages this morning so I'm up to date. <acrow>But other pages work just fine.... <RavenJoad>acrow: Wikipedia of Guix works for me, so at least my nyxt is not super broken. <acrow>Maybe I need to also install gstreamer? <nckx>Yes. Adding gstreamer gst-plugins-{base,good} fixes it. <Guest69>Since I added an mcron job, I can't reboot my rpi. Was this may some bug in Guix, since I can't use latest revision? <nckx>Our site is too multi-medial. <nckx>Eh, not including the -plugins makes it crash even before start-up. <acrow>Is it our minimalistic tendencies that prevent us from adding gstreamer to nyxt as a propagated input? or is there a better reason? <nckx>We don't have minimalistic tendencies *points at graph*. <nckx>However, we shouldn't randomly propagate things without understanding why there's no better alternative (and generally, IMO, all alternatives are better). <nckx>Problem is I don't know the first thing about real-boy Lisps and how we'd point it to gstreamer without propagation. <nckx>You need only a few well-placed propagations to make an entire desktop installation a monolithic clump that needs to be upgraded in lockstep. <Guest69>I added a job that runs every minute. Now I removed it and reconfigured the system again. "herd schedule mcron" does still show jobs for the one I removed <Guest69>I ran "herd restart mcron" and "herd schedule mcron" still shows it <Guest69>adding gnupg as package input does give an error of undefined variable but does not say which module needs to be imported. This happens on some packages. Is this an error since it is inconsistent? <nckx>‘error: gnupg: unbound variable | hint: Did you forget `(use-modules (gnu packages gnupg))'?’ <Guest69>interesting. I am not on the latest revision. Maybe it was fixed some time ago? <Guest69>Authenticating channel 'guix', commits 9edb3f6 to bd7bb47 (1,758 new commits)... <nckx>Guest69: With this ‘old’ guix, does ‘echo "((@@ (guix ui) known-variable-definition) 'gnupg)" | guix repl’ return an object or #f? <nckx>Maybe this happens when you don't import (gnu packages) or so… <nckx>…that's 100% a guess though. <nckx>I forgor that my ~/.guile *does* import (gnu packages), so I guess this would be a more fair test: echo -e ",use (gnu packages)\n((@@ (guix ui) known-variable-definition) 'gnupg)" | guix repl <nckx>guix repl could use an -e option if only for IRC. ☺ <nckx>ACTION still mostly away, not really available, but good luck. <Guest69>guix (GNU Guix) bd7bb4794400ee0cbffda52846f6464a5390ea5b, well turns out I accidentally ran those cmds with the new version since I opened a new terminal. Anyways going to reconfigure system <apteryx>we need a script that checks issues in debbugs and closes those already committed <apteryx>(if the commit subject matches, e.g.) <jpoiret>huh, an ocaml project for coq that uses a js test framework? <nikolar>why would you ever use js if you have a choice not to 