<atka>I get guix error: substitute died unexpectedly a few times a week when reconfiguring, I can re-run guix system reconfigure and it will work. when a substitute dies does that failed transaction leave anything behind? garbage collection should clean up that sort of stuff yes? <vagrantc>Aurora_v_kosmose: unfortunately, the occasional ping is sometimes necessary ... <Aurora_v_kosmose>vagrantc: How should I proceed? Just posting something like "bump" to the email thread or some other way? <vagrantc>Aurora_v_kosmose: something as simple as "bump" or "ping" have definitely been used... just be sure to keep it fairly freidnly, as everyone's a volunteer :) <vagrantc>is it an update or a new package? sometimes pinging someone who worked on it in the past or related packages is ok, too <Aurora_v_kosmose>vagrantc: It's an update. It's basically fixing a package that hasn't been building for a year. <gnucode>ok my <opensmtpd-configuration> project is no longer a toy. I am getting somewhere!! <vagrantc>Aurora_v_kosmose: which on? i can give a shot. though i'm not too savvy :) <gnucode>I have to figure out how to print the filters, but after there there aren't too many more tough problems to solve. <Aurora_v_kosmose>Disabling tests isn't an amazing way to fix the build but the upstream situation with regard to its dependencies is a bit weird. ***rekado_ is now known as rekado
<vagrantc>Aurora_v_kosmose: it looks like your revision change isn't quite right, going from revision "2" to revision "0" ... the revision for git commits (unless the base upstream version is also updated) should always increase <Aurora_v_kosmose>Ah, I had been under the impression revisions were for Guix-side changes between package versions. <vagrantc>Aurora_v_kosmose: also, include a comment in the code about which parts should be removed and when, rather than in the commit message <vagrantc>Aurora_v_kosmose: well, the git commit isn't consistently incrementing, so when using git-based versions, you need some sort of incrementer to ensure version updates. i think in this particular case, the git commit version is "newer" in a version-string sense, but you won't want to rely on that <vagrantc>Aurora_v_kosmose: this code is a little outside what i would feel savvy enough to merge, but i think those changes would be good improvements for a v4 series <vagrantc>Aurora_v_kosmose: mostly because i don't know the codebase at all, but what i can figure from packaging <vagrantc>Aurora_v_kosmose: maybe merge commits 1 & 3, if i'm reading correctly that they're modifying the same package <vagrantc>and there should be a * gnu/packages/machine-learning.scm (PACKAGENAME): change1 ... changeN in the commit message for each commit <vagrantc>Aurora_v_kosmose: have you run "guix lint PACKAGE" ? that might find other things to fix <wdkrnls>Odd, my guix system reconfigure failed because some mapped command got a list of strings instead of a single string. <wdkrnls>where the string is a list of .pub files <Aurora_v_kosmose>vagrantc: I now have. "kaldi@0-3.dd107fd: label 'gfortran' does not match package name 'gfortran:lib'" and "kaldi@0-3.dd107fd: label 'glib' does not match package name 'glib:bin'" . That fortran one is most puzzling because as far as "guix search" goes, gfortran doesn't exist as a package at all. <wdkrnls>I think I just put a paren in the wrong spot. <vagrantc>Aurora_v_kosmose: i wonder if those are things guix lint could be made smarter about ... <Aurora_v_kosmose>Possibly, but I don't feel particularly comfortable trying to modify that. <wdkrnls>I fixed the location of my paren and it sort of finished building. I got a couple of scary warnings though. <wdkrnls>namely one warning suggests that the kernel debugging systems "could not be upgraded". <vagrantc>Aurora_v_kosmose: oh, more i was saying i think that's more bugs in guix lint than anything you need to fix :) <wdkrnls>guix system: warning: exception caught while executing 'start' on service 'file-system-/sys/kernel/debug' <wdkrnls>Throw to key `match-error' with args `("match" "no matching pattern" ("none" "/sys/kernel/debug" "debugfs" () #f #f #f #t preen))'. <vagrantc>Aurora_v_kosmose: well, hope that was helpful. heading off now <wdkrnls>gah, might still be some parens issues. trying again. I don't know why Guix has to keep redownloading the packages. You would think it could cache them to save on bandwidth and time. <wdkrnls>I'm still having trouble with herd and emacs. <wdkrnls>At some point in the past I updated it and suddenly herd would no longer let me spawn a server and let me create new emacs frames for it. <wdkrnls>the emacs process appears to start, but emacsclient tells me it cannot access the server <wdkrnls>when I can server-start in emacs, it complains there is already a server running. <wdkrnls>it's really frustrating because I setup my entire window manager around emacs. <wdkrnls>So I gave up for a bit and started using GNOME, but it kept popping up with a dialog asking me to sign into Google services. I couldn't abide by it. <wdkrnls>So I am trying to make a new system configuration without it installed. <wdkrnls>so many problems I keep trying to tackle in a sort of lazy iterative manner: try 1, it fails, try another, it fails, move onto the next. <wdkrnls>hopefully at some point I will arrive at the system working the way I want it to. <wdkrnls>And I can finally get on with doing the things I wanted to do in the first place. <littlebobeep>wdkrnls: What? What does GNOME have to do with Google accounts? <wdkrnls>gah, I'm still getting that exception for the kernel debug I pasted earlier. <wdkrnls>Throw to key `match-error' with args `("match" "no matching pattern" ("none" "/sys/kernel/debug" "debugfs" () #f #f #f #t preen))' <wdkrnls>whatever it is, it pops up on its own over and over again. <wdkrnls>Could this error be something about guile changing semantics? ***shtwzrd[m] is now known as Brandong[m]
<littlebobeep>drakonis: I don't use GNOME but I would be surprised if they integrated Google account into it <lilyp>GNOME did integrate Google into the filesystem, calendar and mail through GOA. <lilyp>On first setup, GNOME asks you whether you want to add such an online account, but you can skip that check and it won't be shown again ***lukedashjr is now known as luke-jr
***alMalsamo is now known as littlebobeep
<kitty1>lilyp: does guix have flags to disable that type of integration? I don't know GNOME but the type of person who would, would probably be the type of person things like firefox being excluded are for. ***dgcampea-2 is now known as dgcampea
<jpoiret>kitty1: guix doesn't have a flag system à la gentoo. You can however customize any package in the dep tree using package transformations and package rewriting techniques *attila_lendvai facepalms for sending a mail to the list that he explicitly didn't intend to... <rekado>pushed as 4d336ecf200e1011eed6433f4a74e3fa7272b3af <tschilptschilp23>This might be a somewhat strange questions -- how would I map something like ~guix shell glade gnunet gnutls gtk libextractor libgcrypt libunique qrencode pkg-config libglade gcc-toolchain make -D gnunet glade~ to a package config regarding inputs, native-inputs, and/org propagated inputs? I'm asking, because this environment seems to let me compile gnunet-gtk, that SuseJdoG mentioned yesterday, in the 'classic' ~./configure <tschilptschilp23>--prefix=somewhere && make && make check && make install~ way. The produced binaries seem to work more or less. Although probably the most interesting one ~gnunet-fs-gtk~ produces an memory access error when run as user and bails out not finding gtk-icons and/or gdk-pixbuf when run with sudo. Nevertheless configure at least finds the needed gnunet-headers that way. <tschilptschilp23>the actual shell package list preceding ~-D~ is actually a bit longer, but this probably unsupported/unsuggested way was the only way I managed to make configure see the headers... <tschilptschilp23>compiling ~gnunet~ itself with the same 'technique' (but without ~-D~) also produces binaries, but these don't compare to the ones packaged in guix in functionality. I guess it's just not meant to be done that way? <tschilptschilp23>To avoid confusion -- I've tried both the gnunet-gtk sources from git and ftp.gnu.org. <jpoiret>hmmm, you shouldn't run make install ever <jpoiret>everything should be under inputs, except pkg-config methinks <jpoiret>pkg-config should be under native-inputs <jpoiret>and every lib that's Required by the .pc file should be propagated (pkg-config things) <tschilptschilp23>where should this .pc file be located, or are there alternate namings for this entity? I'm asking because this ~find git-projects/gnunet-gtk/ -type f -name "*.pc"~ outputs 0 files... <tschilptschilp23>there a pkgconfig directory exists with a .pc for pretty much every service... <unmatched-paren>we could use it to remove the python dependency for packages using meson-build-system that wouldn't otherwise need it <unmatched-paren>probably slightly less useful for guix, since our main C compiler is also a C++ compile <Basspoon>Hi, I'm new to Guix and was wondering if there's a way to only upgrade packages that have an available substitute when running 'guix upgrade'. I've already added this snippet https://guix.gnu.org/manual/devel/en/guix.html#Channels-with-Substitutes to my channels.scm, but as the manual states, this only stops 'guix pull' from compiling package definitions. Please let me know if this is the wrong place to ask. Thank you. ***wielaard is now known as mjw
<civodul>Basspoon: hi! this is the right place to ask <civodul>you can generally try "--dry-run" to see what would get built <civodul>but there's currently no --upgrade-only-if-substitutes-available flag <civodul>problem is that this could lead to security issues, if you end up running old vulnerable software <Basspoon>Thanks for your help :) I considered that, but was curious if there was a better way. I guess it doesn't really matter, since I only need to avoid compiling big packages like linux-libre or ungoogled-chromium <tschilptschilp23>Basspoon: I've put the critical packages (my computer also starts burning on ungoogled-chromium, gimp and linux-libre too) into a manifest-file, which makes it 'comfortable' to selectively 'guix weather -m critical-manifest.scm' peek into the new guix and in the not-ready case switch back. *tschilptschilp23 now thinks that writing manifest-files for achieving ~guix weather ungoogled-chromium linux-libre gimp~ might be overkill <Basspoon>@tschilptschilp23 by 'switch back' do you mean you avoid upgrading those packages (for the meantime)? <tschilptschilp23>yes, I'm not sure if this is good practice, but I typically do ~guix pull~, then ~guix weather ungoogled-chromium linux-libre gimp~ (well, just now switched to that instead of the manifest 'technique'), and if substitutes show less than 100% run ~guix pull --switch-generations=PREVIOUSNUMBER~. From then on I do a ~guix pull --switch-generations=NEXTNUMBER~ and 'guix weather ...' to be aware of substitute-readiness and just by then <tschilptschilp23>upgrade. That way I'm a few days late all the time, but at least do not put my computer into an unexpected fullout-compilation mode. I basically keep the 'old' guix until these packages are readily substituted, but do the check quite often to stay up-to-date. ***unmatche1-paren is now known as unmatched-paren
<tschilptschilp23>but maybe I'll stay with the manifest (containing actually all packages I have in my profile) anyway, as I just see plasma-packages for marble rolling in and wonder how long this will take... <tschilptschilp23>yeah, manifests will stay the way for me. If I'd be a crypto-affine person, I'd probably like what's going on right now, but I'm not really. <Basspoon>@tschilptschilp23 may I ask what you're referring to by 'source-packags'? <tschilptschilp23>the *.tar.xz and *.tar.gz packages, that you see being downloaded when upgrading. <Basspoon>Oh, I thought you might've been referring to something else <tschilptschilp23>which undergo the configure, install, check phases before they turn into these .drv files <tschilptschilp23>If I'd know that my laptop somehow contributes to guix with the 'compilation' process, I'd probably be fine, but without knowing it, I do not really like the the update/upgrade procedure that we have. except for the possibility to roll-back through time and space. <jpoiret>tschilptschilp23: that's the opposite though, it's the .drv files that tell them how to configure install and check <jpoiret>when guix says `building /gnu/store/xxxx.drv`, it means that it's building the derivation (which is that exact file) <jpoiret>not worries, it's just an excuse to distill guix internals on the chat :p <wdkrnls>can I place multiple expressions under modify-services e.g. (modify-services *service* expr1 expr2 expr3 etc? The docs look like they say yes I can, but I didn't really see any examples which show that. <wdkrnls>and I'm still seeing the debugfs throw error. *tschilptschilp23 would have an easier live, if progress bars would not affect attention <wdkrnls>thanks, then it sounds like maybe that warning isn't as serious as it sounds. <wdkrnls>I'm just haven't managed the courage to try restarting my computer yet. <wdkrnls>nope, it's just coming up as a warning when I try to reconfigure the system. <wdkrnls>it looks like its coming from a guile pattern matching form. *tschilptschilp23 understood that progress bars mean 'have a walk in the sun and get some food' ;) <wdkrnls>in some condition systems, there is an option to turn warnings into errors. <wdkrnls>it would seem nice if that was possible for a system reconfigure. <wdkrnls>that way I could trigger a more detailed trace for what is going wrong. <reza[m]>I am not able to generate plots with matplotlib <reza[m]>I get: UserWarning: Matplotlib is currently using agg, which is a non-GUI backend, so cannot show the figure. <reza[m]>I tried installing python-pyqt and tk but I always get the same output <reza[m]>to reproduce: `guix shell python-matplotlib -- python3 -c "import matplotlib.pyplot as plt; plt.plot([1,2,3]); plt.show()"` <wdkrnls>I haven't used matplotlib for a while. Where do expect the plot to go? don't you need to pass a file path somehow? I remeember it used to create a little GUI widget, but I don't know what configuration allowed that to be created. <reza[m]>according to the matplotlib documentation it should detect an avilable backend and create a gui window with the plot <wdkrnls>can you change the backend to qtagg instead? <wdkrnls>I remember agg hiding the plot when I was trying to use matplotlib from within a browser and changing the backend fixed it. <reza[m]>I tried to set env var MPLBACKEND to qtagg resulting in the same warning <attila_lendvai>if i want mcron jobs to be run from ~/.config/cron/foo.guile then i need to run mcron as my user, right? but how or from-where should i start it? the doc doesn't say anything... <reza[m]>reza[m]: which is strange because python-matplotlib depends on python-pyqt <wdkrnls>attila_lendvai: I wish I remembered. I had it figured out at one point. *attila_lendvai puts an `mcron --daemon` at the end of his .profile and will see... <gnoo>attila_lendvai: try a user-shepherd <wdkrnls>I thought they were different. I also have some shepherd user services defined. Of course, the stopped working too. <wdkrnls>I used to have emacs restart automatically with a server if it crashed. <gnoo>yeah, they're different but you can start mcron from shepherd <gnoo>then you can restart or stop or disable with shepherd easily without say re login or dedicating a terminal for a service <tschilptschilp23>reza: this seems to work here: ~guix shell python-matplotlib python-tornado -- python3 -c "import matplotlib; import matplotlib.pyplot as plt; matplotlib.use('WebAgg'); plt.plot([1,2,3]); plt.show()"~ <reza[m]>although I don't want to use `matplotlib.use` <gnoo>how do you specify a package's location while building a package? i want to replace #!/usr/bin/perl with something like #!/gnu/store/...perl../bin/perl in a file <reza[m]>thanks, not my desired solution,but one I can work with <reza[m]>reza[m]: just `export MPLBACKEND=WebAgg` <reza[m]>you could also set `backend: webagg` inside the file `matplotlibrc` <apteryx>civodul: hello! I haven't tried your latest guile-zstd benchmark yet, but based on my last findings, I believe it'll be aligned with your results (i.e., there is no problem with guile-zstd itself when it comes to decompression performance) <apteryx>In light of this, I think your idea to had the index.db pre-computed per package and merged in a profile hook is currently the path to pursue <civodul>apteryx: hi! ah yes, in general, if we could replace hooks by a cheap merge of pre-computed data, that'd be great <civodul>the less computational and i/o work in hooks, the better <apteryx>you're welcome, thanks for this addition <wdkrnls>well... I guess I am happy ignoring my kernel errors since restarting worked anyway and the system upgrade fixed my shepherd user jobs. <wdkrnls>now back towards actually figuring out how to productively use guix... <wdkrnls>how do you work with additional guix profiles from the same emacs installed in the default user profile? <wdkrnls>I guess, the simple concrete task I want to accomplish is to start an R interpreter from another profile in my default emacs through the "Emacs Speaks Statistics" environment. <jpoiret>wdkrnls: the issue is that activating profiles is only supported either in posix shells or pure guile <jpoiret>but as long as you don't need to set env variables for things to work you could directly use the interpreter located in the profile <jpoiret>i doubt it'd work if you need other R packages though (but i don't know how that language works) <wdkrnls>yeah, other packages is what I'm worried about. <wdkrnls>ESS can work with R interpretters on remote computers though, so I feel like there must be a way. <jpoiret>i guess it should be possible to write a guile script that outputs an elisp script that activates a profile <apteryx>i.e., would it be helful when I want to know the total memory used by a build invoked with make? <civodul>apteryx: it uses wait3(2), which gives resource usage of the direct child only i think? (info "(libc) Resource Usage") <wdkrnls>why would you need a guile script versus a bash script like in all of the examples for activating a profile with . path/to/profile/etc/profile? <apteryx>civodul: eh, "‘wait3’ is now obsolete"(d by 'wait4'). <apteryx>civodul: oh, it seems to report for all children when using RUSAGE_CHILDREN (-1), which GNU time does <apteryx>according to the Resource Usage info node you refered to <apteryx>we could use this to monitor resource usage during builds, which would be useful to display how much memory was needed (total and per core, for example) for a build <apteryx>just thinking out loud, but over time data service could amass build statistics that could be queried by users wanting to have an estimate of how long their source build will take or whether they have enough physical memory <civodul>actually i used "\time make" when profiling 3.0.8, for instance <civodul>i haven't yet been able to do much with it <civodul>but i think we should set up something along these lines <apteryx>hm, GNU time seems to report memory usage only for one (child?) process; here's a failed build of webkitgtk when using CMAKE_BUILD_TYPE=RelWithDebInfo: 'cpu: 1125%, mem: 4049656 KiB, wall: 24:52.82, sys: 1445.89, usr: 15355.58'; that's on a machine with 32 GiB of RAM and 16 GiB of swap. <apteryx>So time reports a usage of 4 GiB, which is probably the usage of the more demanding cc1plus process killed by earlyoom due to exhausting memory and swap exhaustion. <apteryx>civodul: thanks for the guix-benchmarking link <apteryx>AwesomeAdam54321: using G-Exps would be a more future-proof way, depending on what you are attempting to achieve; seems perhaps you were missing #:use-modules (guix gexp) at the top of your module? <civodul>apteryx: for big C++ packages, found it useful to builds with -g0 (not emitting debugging symbols) <civodul>that saves a lot of disk space, but it might save memory as well <apteryx>yes, that's why webkitgtk was using the "Release" build type; unfortunately that means there are not much debug symbols going to to the "debug" output <apteryx>I'm now retrying the build with with -fuse-ld=gold (and ld-gold-wrapper added as an input) <apteryx>as ld.gold requires much less memory than the standard ld <apteryx>and the previous build failed near the end, during the final link it seems <apteryx>it looked better, but still failed on 24 cores, although it reached this 5 minutes faster <apteryx>confirmed by someone in #webkitgtk (gnome server) that debuginfo would mostly impact linking; so using ld.gold to bring this back down seems reasonable <apteryx>civodul: by the way, for the new inetd-style sshd service, is this expected in the output of 'herd status sshd': Running value is "#<input-output: socket 31>". ? <ZhuZihao[m]>The interesting thing: This bug is introduced 3 years ago. pitivi is packaged 1 year ago, I run `guix shell pitivi -- pitivi` and failed to start it and reports gst-python is not correctly installed. <ZhuZihao[m]>🤔 Why the packager of pitivi can run pitivi with a broken python-gst. <apteryx>perhaps the failure depends on the Python version used? <lilyp>kitty1: GOA is comparatively tiny and if you don't like it you probably hate GNOME anyway, so shrug emoji <GNUtoo>Hi, I'm running valgrind in the tests of a package that I build through a guix.scm, and I've the following in the valgrind log: "A must-be-redirected function whose name matches the pattern: strlen in an object with soname matching: ld-linux.so.2 was not found whilst processing symbols from the object with soname: ld-linux.so.2" <GNUtoo>And it proposes that as solutions: "Possible fixes: (1, short term): install glibc's debuginfo package on this machine. (2, longer term): ask the packagers for your Linux distribution to please in future ship a non- stripped ld.so (or whatever the dynamic linker .so is called) that exports the above-named function using the standard calling conventions for this platform. The package you need to install for <mjw>yeah. valgrind really needs the symtab table for ld.so, please don't strip it, it is tiny anyway. <GNUtoo>And it tells to install libc6-dbg or glibc-debuginfo dpeending on the distribution, so I added '("libc-debug" ,glibc "debug")' in native-inputs but that doesn't seems to solve the issue. Does someone has an idea? <mjw>that is odd, my valgrind doesn't say that <GNUtoo>"On Debian, Ubuntu: libc6-dbg" and "On SuSE, openSuSE, Fedora, RHEL: glibc-debuginfo" *GNUtoo is on Parabola i686 with Guix on top, I can try on Parabola x86_64 with Guix <mjw>yeah, we (upstream valgrind hacker here) don't have intructions for guix <GNUtoo>Yes, I was just asking what to do, valgrind probably can't have instructions for each distribution <mjw>So for me, guix system, with valgrind -v true it says (among lots of stuff): <mjw>--19212-- Reading syms from /gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/lib/ld-2.31.so <mjw>And indeed that has a .symtab section and eu-readelf -s shows lots of symbols, including strlen <mjw>GNUtoo, so, first try to find out which ld.so it is trying to use with valgrind -v ... <GNUtoo>I'll try on x86_64 and then I'll do that <mjw>GNUtoo, then see if the ld.so has its .symtab stripped. <mjw>I think so. /me isn't really a guix hacker... <GNUtoo>I'll patch the tests to use valgrind -v *mjw is using an ancient guix install. Maybe it is a recent change. <GNUtoo>Reading syms from /gnu/store/0iapawfss4xnxls622g23qpk4mwb9ihp-glibc-2.33/lib/ld-2.33.so <mjw>guix install: warning: Your Guix installation is 87 days old. <GNUtoo>object doesn't have a symbol table <mjw>right, that is 2 versions of glibc higher than I have locally. <GNUtoo>The issue is that I've no idea how it's supposed to find the debug symbols by itself <GNUtoo>Maybe their path is supposed to be in the ld-2.33.so ? <mjw>GNUtoo, yes, kind of. <mjw>eu-readelf --strings=.gnu_debuglink ... ld-2.33.so should show it. *GNUtoo could try to define a system.scm for a vm too <mjw>But it is normally only a base name <mjw>And then valgrind searches for it under /usr/lib/debug/... <mjw>but... guix doesn't have /usr/lib/debug/... <GNUtoo>and then there are some empty 11, 12, 13 entries and then 1 entry with garbage lke [ 14]- �ZX� <mjw>so if you do have the debug package installed you need to let valgrind know where <mjw>yes, after the string is the CRC checksum <GNUtoo>Ah and there is probably /usr/lib/debug/ somehow with guix system <mjw>There is valgrind --extra-debuginfo-path=path absolute path to search for additional <mjw> debug symbols, in addition to existing default <mjw>But really, please don't strip ld.so :) <GNUtoo>That's probably easier than using --extra-debuginfo-path, and certainly cleaner <mjw>Sorry for being not that helpful. I really should make sure valgrind works well on guix. <mjw>Also have to drop out to get some food for now. Back later. <GNUtoo>With --extra-debuginfo-path I need to add support for it in my python tests, and somehow add an option in configure.ac and somehow retrieve that in the Makefile.am to pass them to the tests through an environment variable... <GNUtoo>And the issue is that even if I manage to do a patch, it'll probably take some time before it's merged <GNUtoo>And it'll probably get in Guix at the next release because if you rebuild glibc everything on top is probably rebuilt <GNUtoo>Hmmm maybe patching the tests in the guix.scm to use an extra argument looks better <GNUtoo>(1) It works now and it's self contained (2) It doesn't make the libsamsung-ipc code complicated because of some Guix limitation. And then the ideal would be to remove that extra patch when Guix will be fixed. <tschilptschilp23>before getting lost in circle-games, I'd be happy to have feedback on one assumption. If I spawn an environment using 'guix shell', there is a file $GUIX_ENVIRONMENT/manifest. This file contains all the information about the environment I'm in at this moment, like the one in ~/.guix-home/profile/manifest, when I'm outside of this environment (assuming I have nothing installed via 'guix package -i', just relying on my home-config.scm). <GNUtoo>Even if the generated code is ugly (over 80 lines) that should work. <GNUtoo> guix package -s binutils-cross returns nothing for me <GNUtoo>but opensbi-generic has binutils-cross-riscv64-linux-gnu@2.37 as depdency <GNUtoo>So it probably requires to do something like a riscv toolchain package <GNUtoo>there are things like arm-none-eabi-toolchain already <jpoiret>GNUtoo: not sure it would change much but glibc:debug shouldn't be a native input, but a regular input <jpoiret>but i think the issue would be that gcc-toolchain needs to be in the inputs as well for the debug symbols of glibc:debug to get picked up (not 100% sure though) <unmatched-paren>GNUtoo: i can't find any riscv toolchain packages at all; maybe they're private (for some reason)? <civodul>unmatched-paren: try "guix build whatever --target=riscv64-linux-gnu"; the toolchain packages are made "on the fly", they're not public ***mark_ is now known as mjw
<KimJongWell>Do you set up a shepherd service somehow to start a container at boot <atka>with guix home are package updates applied via guix pull && guix home reconfigure? <civodul>KimJongWell: hi! what kind of container do you have in mind?