<jaadu>Hello, I believe that my guix installation is broken. I am using the binary installation on a raspberry pi. ***bkv is now known as bqv
<jaadu>A simple guix pull gives me an error. <jaadu>I lack experience of guix so I don't really know where to start looking. <lfam>jaadu: What CPU architecture are you using? <lfam>Can you give any more detail about your system? <lfam>Hm, 32-bit ARM? Or 64-bit? <lfam>If you don't know the answer, then which version of the raspberry pi? <lfam>You could probably do `lscpu` <lfam>Oh, I see in your log that it is 'armhf', which is 32-bit <jaadu>quite sure its a pi version 3 <lfam>Can you share the end of the log referred to at the end of your paste? <vagrantc>pi 3 is 64-bit capable, but rasbperrypifoundation.org images may still be armhf ... <lfam>I was about to point that out <lfam>jaadu: It says "View build log at '/var/log/guix/drvs/sk/kahfzp9mkzksf0ncc6cy3vab3gh60p-guix-packages.drv.bz2'." <lfam>Ohhh, I see you did share it <lfam>Sorry, I was going on and offline <vagrantc>though technically, you could probably run guix's aarch64 on rpi 3 with armhf raspbian <jaadu>It is what I got from the installation script <lfam>Hm, the log is not very useful in this case... <lfam>vagrantc, you are way more knowledgeable about ARM than me... hopefully you have some ideas for debugging :) <lfam>I don't really know where to start <lfam>I wonder if the armhf / aarch64 mismatch is to blame <vagrantc>either should work ... but you might want to explicitly pick aarch64 version <vagrantc>does guix have a way to report what architecture it is built for? <jaadu>Wait, I just noticed that one important line of the log is omitted: <jaadu>builder for `/gnu/store/skkahfzp9mkzksf0ncc6cy3vab3gh60p-guix-packages.drv' failed due to signal 11 (Segmentation fault) *vagrantc <- so helpful :) <lfam>That's why I suspect some architectural confusion <lfam>vagrantc, do you use Guix on armhf? <lfam>jaadu: Does your Pi have 1 GB RAM? <vagrantc>lfam: not regularly, but i have a few machines i boot now and then to make sure it still works <lfam>Okay, that's good to hear <lfam>I wonder if 1 GB is enough to build guix-packages <jaadu>And I havent started X so it should have memory to spare <vagrantc>lfam: mostly a veyron-speedy (a.k.a. ASUS C201p) and a novena <lfam>I think some work has been to improve memory requirements in the Guile compiler but not sure <lfam>jaadu: Something you could try is to wait a while and then try again, pulling the same version. For example, `guix pull --commit=f00e68a` <lfam>That way, you should get "substitutes" for these builds, and thus wouldn't have to build it yourself <lfam>It's not really a "fix" but if the problem is limitations of the hardware, it could help <vagrantc>armhf has been pretty far behind on substitutes and aarch64 often lags too <lfam>You might also try to ensure that you have a GB of swap, but swapping to a microsd card will be slow. I would also consider enabling zram <jaadu>I thought package versions on different architectures were the same. <lfam>They mean that the building of binary substitutes lags behind, due to slowness and relative unreliability of the armhf platform <lfam>So, it's more likely that one will have to build things from source on armhf than, for example, x86_64 <lfam>It "shouldn't matter" but in practice it sometimes does <lfam>I'm testing a similar build in a 1 GB RAM system now, to check if it's enough <lfam>I hope we can come up with a solution for you <lfam>Regarding the building of substitutes, it's challenging for armhf (32-bit ARM) because there aren't any "server quality" platforms for this architecture <lfam>It's hard to find armhf machines that can reliably compile things 24/7 <lfam>We had similar trouble with the 64-bit MIPS architecture, "mips64el", and eventually we stopped supporting it. But there is a lot more demand for armhf <jaadu>Shouldn't any architecture be able to build for any other platform? <lfam>Yes, in principle, but we prefer to do "native builds". I actually don't know much about the trade-offs involved and how they inform the design of the build farm <xelxebar>Yeah, I had an x86_64 machine with binfmt setup to build armhf stuff. Unfortunately, some packagages just don't cross-compile well. I remember cmake having problems with compiler-detection. <jaadu>Hmmm, other commands give me errors. `guix describe ` gives me: `guix describe: error: failed to determine origin` <lfam>jaadu: That's expected if you've never run `guix pull` successfully. <lfam>You can get more basic info in that case with `guix --version` <lfam>So, I can confirm that you'll need more than 1 GB RAM to do `guix pull` without substitutes <lfam>I don't get a segfault but it does run out of memory <lfam>To work around this issue, you could try pulling an older commit or use swap <jaadu>Is there a way to only use substitutes? <lfam>No, not currently. Guix is designed as a build-from-source distro that can transparently use "binary substitutes" when they are avaiable <lfam>It's a common request, however, and work is underway to implement it <lfam>Also, the availability of substitutes is recognized as something that needs to improve <lfam>But that doesn't help you today... <jaadu>Can you give me a few weeks old commit revision? <lfam>Did you start by installing version 1.2.0? <procra>I belive that guix containers wasn't thought with security on mind (if I'm wrong pls tell me) so y try to use linux containers on virt-manager and i got an error however in don't know if is because the way guix manages directories or because I forget an step again ... probably on user permissions or on a daemon. <lfam>jaadu: Maybe try commit 6718ce446c3904214697cde8eb666fe86368d034 <lfam>What did you try to do procra? <procra>i try to setup an aplication container for icecat in order to use it in a more secure way <procra>i could use a VM but i have really low resourses <procra>and the binary used was under my local path <lfam>If you'd like assistance, please share the full command (or commands) that failed, and the output of `guix describe` <lfam>That will help other people help you <procra>Generation 8 Dec 18 2020 23:58:38 (current) <procra> commit: 712cdf306b09b3a5b27c0f8f42860ede196134fd <procra> commit: 69b98261e7281479d6bd567b8af1b0aa9e3f9abe <procra>that's my output of guix describe <procra>but I use virt-manager for creating the container (lxc) so i don't really know which comands did you need lfam <lfam>I recommend waiting around for a while. I'm sure that somebody will have some advice <procra>if i disconect a moment (i have some internet problems) i will check the web log <blendergeek>I am trying to use a network printer in GNU Guix using EXWM. When the print dialog comes up, my printer is shown, but its status is "Getting printer information" and the "Print" button is greyed out as if I hadn't selected any printer. <blendergeek>No, but on my other GNU/Linux computer (running Ubuntu) it just worked out of the box. Is there a package I have to install or do I have to manually install drivers on GuixSD? <jaadu>Ifam, procra: Using a older revision seems to fix the issue. I will add some more swap and update overnight. Thanks! <lfam>jaadu: Glad to hear it! I hope we can improve the armhf part of our build farm soon <bdju>when will Guix have linux-libre 5.10? I have 89 days uptime and I think I'll reboot once I can install 5.10 <bdju>(maybe no one knows, in which case any news or guesses are welcome too) <vagrantc>looks like linux-libre has 5.10.2 ... but updating to a new major version is often an adventure in guix <Black-Mug>im downloading guix 1.2 but the speed is less than 200kb per hour is this normal? <sundbry>@bdju I suppose it should not be very difficult to swap the version numbers in linux.scm and build the kernel package from source. ***lukedashjr is now known as luke-jr
<lfam>vagrantc: I'm curious to hear more about your adventures. For my simple use cases on x86_64, these major upgrades are typically painless <lfam>bdju: We've had 5.10 for for about 2 days now <lfam>vagrantc: I usually don't get any feedback on the update patches, so I just make sure it works for me and push. It would help me feel more confident if I could get more people to test and give feedback <bdju>lfam: oh, okay. I checked with guix search and saw an older one (thought I'd done a pull recently...), then I checked the guix ci web thing and didn't see it there. I guess I didn't know where to look <bdju>and thanks vagrantc too for checking <bdju>sundbry: I have yet to do a package modification like that. I probably won't do it here, but out of curiosity, what's that process like? the .scm files are read-only, right? so you probably have to copy them, modify them, then do *something* to install them I would guess <sundbry>well you should definitely start with something simple then. You dont ned to modify the core guix packages, it is sufficient to import them and extend over them in your own source files. guix package -f <my-file.scm> will install a custom package definition <bdju>what do you do for things where the definition is part of a larger file? if you just copied their part out you'd be missing the use-module stuff I figure <bqv>Guixers, what do you do when you need something not yet packaged? <bdju>like if you were modifying a game, would you copy the whole games.scm? <bqv>(and cannot package it) <bdju>bqv: I put it on the guix wishlist on the libreplanet wiki <bqv>does it happen often? <bdju>I have enough things packaged to do day-to-day things, but it's common to come across something in the wild that's not already packaged. I have added dozens of entries to that list <bqv>I see! Also, is there a feature a-la flakes in nix, for guix? <bdju>I used NixOS in the past but I'm not familiar with flakes, hopefully someone else knows <lfam>bdju: Hm, well the definitive answer to "what packages are available" is `guix search` or `guix package --list-available`, but of course it only shows the `guix pull` that is currently effective <lfam>Unfortunately, the CI web site is going through a rough patch and can't really be relied upon for this kind of search right now <sundbry>You could then use that base definition to point node to a different source code for example with the same build script, or add a stage to the build process to load some custom patches <sundbry>that node package can be built with guix build -f <file.scm> (build only) or installed with guix package -f <file.scm> <bdju>sundbry: interesting, I sort of get it. so because it builds on the existing package, it doesn't need much info... so you could use this to replace the source for a package while keeping the dependencies, build system, and so on the same as the other version? <sundbry>this is an example of a grpc toolkit from scratch, since the one in guix/modules/rpc.scm did not have all the features i wanted <sundbry>in this case it was just easier to write from scratch <lfam>Sorry to jump in, but if a Guix package is lacking some useful features, please ask us to add them :) We aim to provide fully-featured packages <sundbry>bdju: yes exactly, you can just change the name for example or the description of the package, or insert some --configure flags <bdju>thank you for the explanation and examples <sundbry>the guix source code is really the best documentation though, although the manuals are necessary for a deep understanding once you get into it. <sundbry>it helps if you have a basic lisp primer before jumping into it <bqv>Guix is lovely, I want to love it, but I'd miss is flakes, lots of packages, and nix's huge community <barbanegra>bqv: you can love multiple free software packages <sundbry>I would not use guix if i just wanted an 'it just works' desktop os, it is really useful for building software <Aurora_v_kosmose>cl-cffi has broken for SBCL >=2.0.10, I'll have to check if later releases fix it. <bqv>barbanegra: I can't easily *use* both though :p I'd know, I tried, by making the guix module for nixos <barbanegra>More than many other 'stable' or 'corporate' distros <sundbry>Yes I just mean plaing to its strengths. If you are not ready to package some one off software you need you might be disappointed <sundbry>for example installing binar packages can be very difficult. I had to work very hard to get IntelliJ to run <sundbry>you can kind of cheat with flatpak but that has its own disadvantages <sundbry>because most of the c libraries are not in the 'normal' place <sundbry>but alas I can get any intellij/Clion/ etc working now, I will be happy to share if anyone misses that software.... <sundbry>@Aurora_v_kosmose I use guix environment to load the environment for the software I am building, then launch CLion *inside* by custom environment. it is kind of awesomely reproducible <bqv>See its interesting for me, too. I have nixos on my machine, but rather than use the guix module I actually have guix installed to ~/gnu in a permissionless way, using linux namespaces. So, I can use both, but I have to run all guix things in that ns-env <bqv>It was great for that one package thats in guix but not nixpkgs :O <bqv>I'm thinking I might make guix more part of my system, bake it into my config more, but its hard because it can't be "locked", so it kinda becomes one massive bit of imperative state <Guest23424>hi #guix! does anyone know where I can find the source for the installer? <Guest23424>lfam: this looks like the installer image. do you know where the installer (graphical tool) code is? <lfam>Glad you found it. I misunderstood your question <procra>it looks that I have to use cgroupsv2 <vagrantc>lfam: not sure what all to say ... i remember i did one major version update a while back but didn't manage the kconfig upgrades very well <vagrantc>lfam: for armhf and aarch64 ... it's a little more tricky partly because the exact modules or builtins needed change more often between releases ... and guix not having modprobe in the initrd makes it extra complicated <vagrantc>lfam: not a lot more to it than that, though :) <aecepoglu[m]>I'm trying to create a guile development environment where I use guile-curl. But `(use-modules (curl))` gives errors <efraim>did you specify guile in your environment also? <efraim>are you using 'guix environment --ad-hoc guile-curl' <aecepoglu[m]>`It's not possible to set fish shell as login shell now in Guix because fish shell cannot load environment variables from /run/current-system/profile/ ...` means my usage of fish could be the problem ***apteryx_ is now known as apteryx
<civodul>vagrantc: i have some good news and some bad news <civodul>i see where the problem comes from, but i can't think of a good workaround <aecepoglu[m]>Is there an established way to go about extending the contents GUIX_ENVIRONMENT/etc/profile file, so when I create new environments they have a few more lines? <aecepoglu[m]>Perhaps in a modal way. So my ocaml environment has its respective OCAML_LOAD_PATH that instead of GUILE_LOAD_PATH etc... <civodul>aecepoglu[m]: hi! its contents are generated from the 'native-search-paths' fields of packages <civodul>so for example Guile has a 'GUILE_LOAD_PATH' search path, etc. <civodul>the ocaml package has search path specs for OCAMLPATH and CAML_LD_LIBRARY_PATH <civodul>so these two should be set automatically when needed <aecepoglu[m]>I gave ocaml as just an example that isn't Guile :) But I understand <vagrantc>civodul: thanks for the update on guile-gnutls! <civodul>abcdw: on Guix System there's session-environment-service-type <civodul>(per "guix system search environment" :-)) <civodul>you can extend it with additional environment variables (key/value pairs) <abcdw>civodul, thank you for hint. I already saw it, isn't this one is a "system-wide"? <abcdw>The link above contains `~/.config/environment.d/*.conf`, which is something I'm looking alternative for. <abcdw>Something like session-environment-service-type, but for a particular user. Actually even just a hint about way of setting varible will be enough, I probably would be able to implement such service myself. <civodul>abcdw: ah yes, session-environment-service-type is system-wide; there's currently nothing per-user <civodul>apart from .bash_profile, that is :-) <abcdw>civodul, .bash_profile won't set variables for compositor (window manager) and other graphical apps. Trying to find a way to solve it. <abcdw>civodul, probably I'll try to set environment variables for user herd instance and launch window manager using herd. <civodul>there's also .xsession if you use X11 *abcdw went reading shephered documentation *abcdw found $HOME/.pam_environment for setting per-user env variables <mbakke>(before I break all the TeX Live stuff again) <mbakke>abcdw: FWIW I have configured autologin on TTY2, and launch Sway (+ set variables) through '.bash_profile' when on /dev/tty2... Would love to move that configuration snippet out of .bash_profile and into the system configuration though. :-) <abcdw>mbakke, will write to this chat, when will decide on approach to use (: <maav>i'm working on getting an internationalized version of help2man, but I have an issue <maav>the build process generates its own man pages on several languages, but these locales cannot be found on glibc-utf8-locales, which comes from the implicit inputs <maav>what should be the way forward? Providing glibc-locales as "locales" native-input doesn't work when I include (gnu packages base) :-( <mbakke>maav: probably you need to override the 'set-locales' phase? <mbakke>abcdw: oh, it's already deprecated on 'staging' then <maav>mbakke: LC_ALL is changed by the make targets for each translation of the manual, the issue is that they aren't available on the LOCPATH :( <maav>It builds with that "limitation", so I'm opening an issue to follow this up <jlicht>mbakke: thanks for the heads-up, but I think rekado already pushed this commit to wip-texlive <jlicht>or perhaps I did, stay-at-home lockdown days are a bit of a blur to me ;-) <mbakke>oh, there's a wip-texlive branch ... probably that should be merged before I proceed with the TeX Live 2020 upgrade <mbakke>rekado_: what is the status of wip-texlive? should we merge it on 'master' or 'core-updates'? <dftxbs3e>hey, how would you define a package specification with specific output in GNU Guix System configuration? (specification->package "bind:utils") wont work - thanks! <abcdw>dftxbs3e, specification->package+output <rekado_>mbakke: uh, I forgot about wip-texlive <rekado_>it causes lots of rebuilds, so it’s like a little core-updates branch <rekado_>I don’t have any opinion on whether to put it on top of master or core-updates <dftxbs3e>but I tried manifest it didnt quite work <abcdw>dftxbs3e, specifications->manifest is just a wrapper <abcdw> (map (compose list specification->package+output) specs))) <dftxbs3e>abcdw, oh okayy! would be nice restoring the documentation for both! <abcdw>Just use (map specification->package+output '("list" "of" "your" "packages")) <dftxbs3e>(map (compose list specification->package+output '("list" "of" "my" "packages"))) <dftxbs3e>(map (compose list specification->package+output) '("list" "of" "my" "packages")) <abcdw>dftxbs3e, yep, it would be cool to mention it somewhere around specification->package <mbakke>rekado_: since we will start core-updates in a near future, perhaps just add it there instead of another half-rebuild of 'master' <ngz>I have a large amount of simple Rust-related commits (adding new variables, renaming *-1.0 to *-1, etc.) Is there any interest in reviewing them, or shall I simply push them? <civodul>ngz: since there's quite a bit of activity in this area, perhaps you could send a heads-up summarizing the changes, Cc'ing the interested parties <civodul>personally i'm fine either way but i guess those who fiddle with Rust might have a stronger opinion <civodul>is anyone looking at zstd bindings for Guile? <apteryx>Any clue why 'mkdir /tmp/sandbox && cd /tmp/sandbox && guix environment --container -E 'DISPLAY' --share=/tmp/.X11-unix --share=$HOME/.Xauthority --ad-hoc icecat' gives an IceCat that has access to the internet? (note: I am not using the --network option) <apteryx>ah, I think it recycles the existing icecat process <dftxbs3e>hello! how would you make ./pre-inst-env guix include system channel configuration? <davidl>Has anyone packaged or worked on packaing nextcloud or nextcloud-clients? <jlicht>dftxbs3e: you could set GUIX_PACKAGE_PATH to point to a checkout of your channel <jlicht>although you might lose out on fancy features, such as channels with dependencies and perhaps more stuff <dftxbs3e>jlicht, my ./pre-inst-env thing has modifications, will that work..? <dftxbs3e>my channel doesnt have GNU Guix, just things that add to it <dftxbs3e>I tried guix system vm instead with doc/os-config-desktop.texi but it's not working. GDM wont display, it takes 100% CPU and is stuck. <jlicht>dftxbs3e: I can confirm that putting valid blub module with foo package in e.g. '/tmp/test/blub.scm', and then `export GUIX_PACKAGE_PATH=/tmp/test; ./pre-inst-env guix search foo` includes my custom package *mbakke will be mostly AFK for a couple of days <zimoun`>More than 1 old bug closed per day this month, and I could have missed some. That’s cool! Closing not missing. ;-) <civodul>looks like we should really add "di.guix.gnu.org" <civodul>that, and for "discontinuous integration" <cbaines>staging is and has always been discontinous integetration, literally <cbaines>which isn't to say it's not an appropriate model to follow here <ngz>at least, discontinuous integration is better than continuous disintegration. <civodul>thing is, it's more discontinuous than we'd like to <cbaines>yeah, once we can build things for substitutes faster, then staging can be used less frequently and when it is used, merged with less of a delay while waiting for things to build <cbaines>I've also still got the idea of some kind of "cost" metric, which would allow actually making more informed decisions about the impact on build farms of merging a change <zimoun`>the recent patch bug#45006 on Cuirass by mothacehe should really help because it will decrease the IO workload done by GC. <civodul>we could perhaps use data gathered by build farms to have an estimate of the CPU·hours it takes to build a package <civodul>zimoun`: since we build system tests and images less frequently, GC is no longer an issue on berlin <cbaines>civodul, exactly, maybe changing 500 r packages is actually quicker to do than changing a single dependency of ungoogled-chromium (for a build farm capable of X parallel builds with Y cores) <cbaines>and it would be nice to be able to make decisions based on that <civodul>cbaines: IIRC Linux from Scratch has build time estimates <zimoun`>the store is still bigger than necessary; but I have not followed all the recent discussions. <civodul>roptat: do you know how these are collected? <cbaines>that's cool, I guess if build times where known along with some information about the hardware used (cores available for example), then that could be another use for the data <roptat>but basically, they simply use "time" :) <zimoun`>On a relative big machine at work, I have played with cores and max-jobs, daemon side or not. And when I build bunch of packages, it happens more than often than only one core is working, the other waiting even if packages still need to be built. I could have misconfigured something but my guess is the “daemon scheduler” which is somehow blocking. <roptat>the nice thing with LFS time estimates, is that's it's not in terms of seconds, but relative to the build time of binutils, the first package <blendergeek>I am having trouble printing from my GuixSD system. I added cups to my config.scm and it is installed. My printer has a Free driver (which is installed). I installed system-config-printer. My printer shows up when I try to print. However, the "Print" button in print dialogs is greyed out and the "Status" for my printer is "Getting Printer Information.." <roptat>so, as long as you know how long it takes you to build binutils, you have a rough idea of how long it'll take to build other packages, independently of your machine's speed <zimoun`>roptat: smart. But it should per build system. For example, some build parellel, other not. <adfeno>Hi there, I use foreign distro, hit a bug where some package installation completely removes GIO/GSettings schemas of foreign distro, making me unable to login using display manager next time. <adfeno>I don't know exactly which package. <lfam>Is it a new problem for you? <adfeno>Besides, It seems I'm only able to attest if something changed if I login (either through terminal or through displaymanager), because the “current session” gsettings isn't updated in real time. <adfeno>E.g.: suppose gajim is the only cause, if I do gsettings list-recursively, nothing appears. If I then remove gajim, and do the gsettings command again, it still shows nothing (as far as I have tested). <adfeno>If I log out and back in then I see the change. <adfeno>lfam: Ah thanks, will try again with the suggestions made by Carlo. <adfeno>I wonder what is the default for GI_TYPELIB_PATH if it's unset. <adfeno>I'll assume it's somewhere in /usr/lib/ <apteryx>I'm not much of a C programer, but the sources of fontconfig are not exactly obvious (one char parameter names, few comments). I'm trying to have it honor XDG_DATA_DIRS. <apteryx>This would allow software using the fontconfig to discover fonts via the XDG_DATA_DIRS environment variable. <aecepoglu[m]>I have yet to resolve the issue with guix complaining `LC_ALL: cannot change locale (en_US.UTF-8)` <aecepoglu[m]>I have glibc-utf8-locales installed. GUIX_LOCPATH set to ~/.guix-profile/lib/locale under which a folder with value of LC_ALL present <lfam>Is there anything we can do to get it building again? <cbaines>lfam, I'll query for staging substitutes to update the information in the Guix Data Service, I'll let you know when it's done <UnderSampled>I installed Guix a while ago using the installer from the liveUSB <lfam>I'm having a confusing networking problem with a remote Guix system. Guix commands are failing with "guix substitute: error: connect: Network is unreachable", although I'm working interactively via SSH <lfam>I think the wifi card might be failing <lfam>But, it's hard to say what's going on, and it would be nice to improve the behaviour of --fallback so that it really tries falling back, and for --keep-going to actually try the other builds that were going to be performed <dftxbs3e>hello! somehow when I use "./pre-inst-env guix system vm doc/os-config-desktop.scm" QEMU never succeeds at displaying GDM, this means I can't test a system wide change heh.. I also tried doc/os-config-lightweight-desktop.scm same story. How do you test system-wide (GNU Guix System) changes? <cbaines>lfam, I think the staging substitutes data is up to date now <cbaines>although it's not for the latest revision, that failed to process on the first attempt and I'm retrying it <lfam>dftxbs3e: `guix system vm` creates immutable disk images. I think that GDM needs a writeable filesystem to work correctly, so I recommend using `guix system vm-image` or `guix system disk-image` <lfam>Thanks cbaines. These numbers are a little better, but we still have a long way to go <dftxbs3e>lfam, I also tried it by the way, same thing <lfam>Did you make the images writeable after copying them out of /gnu/store? <lfam>I don't know then. There were some bug reports about GDM problems recently, maybe it's totally broken <dftxbs3e>lfam, otherwise, how could I have a "pre-inst-env" but for guix system? <lfam>I don't understand the question <dftxbs3e>lfam, GDM works on my laptop and I use latest so! <dftxbs3e>lfam, like update my GNU Guix System from a modified GNU Guix checkout <lfam>pre-inst-env works for that <lfam>./pre-inst-env guix system reconfigure ... <dftxbs3e>My issue is that it doesnt take into account my system channels <lfam>I don't know... I'm not using channels. Somebody else must have some advice <lfam>You could pull from your local repo <lfam>Yes, using the --url option <dftxbs3e>lfam, I'm trying to fix GNOME Disks so that it has FAT file system formatting support by default <dftxbs3e>It has the UI option by default but then fails with some unobvious error saying mkfs.vfat is missing <lfam>I agree, it should support all common file systems <dftxbs3e>mkfs.fat wasnt included in my desktop profile by default (mostly generated by the GNU Guix installer), dosfstools package <civodul>dftxbs3e: ./pre-inst-env is about using only what your checkout contains <civodul>but you can pass -L flags so that your own modules can be found <dftxbs3e>civodul, I see.. so I need to clone the channel, thanks <blendergeek>Is there something special I have to do to get printing working in GuixSD? <mekeor[m]><blendergeek "Is there something special I hav"> id guess you need to install the cups service <blendergeek>As it is, I have the cups service installed. But I didn't add it at install time but rather later. Do you know where I can find what "printer services" at install time does to the config.scm file? <dftxbs3e>blendergeek, you can try looking in the GNU Guix's info manual for instructions on how to add it. <blendergeek>Do you know what the package name for the installer is so that I can find and try to read its source? <dftxbs3e>* amiloradovsky has quit (Remote host closed the connection) <dftxbs3e>* amiloradovsky (~Thunderbi@2001:4b98:dc2:43:216:3eff:fea7:8a37) has joined <dftxbs3e><blendergeek> Is there something special I have to do to get printing working in GuixSD? <dftxbs3e>* madage has quit (Remote host closed the connection) <dftxbs3e>* madage (~madage@gateway/tor-sasl/madage) has joined <dftxbs3e>* atw (~user@2601:5c2:c500:76b0::d314) has joined