<apteryx>I guess answering my earlier question; the purpose of 'kernel-loadable-module-service-type' is that is can be used to extend the 'kernel-loadable-modules' operating-system field through services.
<unmatched-paren>mike2376: guix will start begging you to pull after a few days of not pulling
<itd_>nckx: a bit late (had to go, sorry), still: thanks for the feedback on the python-mypy patch :) (didn't manage to update bug#54376 in time, but will try to keep it in mind for next time)
<efraim>I reconfigure my machine once a week but update my packages daily
<Guest11>Hi guys, installing and using guix (as pkg manger) from fish caused me loads of headache, question is ... is it even supported? BTW, it works fine from BASH.
<efraim>using fish with Guix isn't as well tested as bash
<Guest11>It's actually close to being compatible with fish, the only issue I see is guix assumes bash syntax when generating profiles, and when fish tries to import it it fails, other stuff (hints thrown by guix) actually work by converting them manually to fish syntax.
<nckx>I kind of get the assumption that ‘your’ shell has to load them because they are ‘shell’ scripts. Shell scripts, shell variables, environment variables, … are so closely associated in most people's minds that it's hard to separate them. But they are separate.
<nckx>itd_: That's all right, it was mainly a future suggestion anyway. Thanks!
<nckx>Hmm, the ‘all Firefox/IceCat tabs crash when swaylocks my screen’ bug is back after a two-month holiday.
<joe153>why does guix pull take so long and it stalls?
<MysteriousSilver>nckx: turns out i had already configured git-send-email years ago but never used it
<maximed>joe153: Among other things, some slowness is caused by the large closure of (gnu packages base)
<maximed>joe153: Also, there was some issue with some rust-*.scm being ‘too’ large, preventing uses of fixnums, so if these rust package files were split off, there could perhaps be some performance increases in that area
<maximed>That happened on 32-bit arches, not 64-arches
<joe153>i dont know why but guix pulls stalls and cpu usage drops form 100%
<maximed>joe153: In my experience, it can be slow, but eventually it will succeed
<maximed>have a look at channels-with-substitutes-available
<fnstudio>but... if i guix install it i get an error: guix install: error: avr-libc: unknown package
<nckx>devmsv: Try adding ‘nomodeset’ to the same kernel command line.
<fnstudio>ah... i see it's defined with define as opposed to define-public
<jlicht>civodul: In case you did not read it, thank you very much for `guix home container'
<vagrantc>fnstudio: would think you could still include it in your package definition
***sneek_ is now known as sneek
<vagrantc>or there's some guile incantation to actually use that package if you're not using a package definition
<fnstudio>vagrantc: yeah, i'm shamelessly monkey-copying the definition in my personal file, shall i rename define to define-public?
<jlicht>fnstudio: it doesn't hurt, but it only makes sense if you are planning to put your personal files in 'proper' guile modules
<fnstudio>jlicht: oh i see, but then - purely out of curiosity - why i'm not able to guix install the definition that's in avr.scm? i thought that was because it's missing the define-public?
<devmsv>nckx: same result. I'm to try to configure the same kernel and initramfs as the installer iso
<jlicht>fnstudio: You could put your personal files into a channel, or put their location in GUIX_PACKAGE_PATH, or add their location via `-L` to some guix commands; Are you familiar with how guile modules work?
<fnstudio>jlicht: i wouldn't say familiar, no, but i've been creating some simple packages and i use -L to build them
<fnstudio>and yes, i have a personal channel for this
<fnstudio>ouch, so i was able to install avr-libc but that didn't help with my qmk error: fatal error: avr/io.h
<jlicht>civodul: RE the blog post, "ten-year birthday" seems a bit weird to me; I'm not quite sure how to improve it though ("10 year anniversary", "10th birthday", or perhaps just "Guix will turn 10")
<nckx>There was a kerfuffle with the Coreboot framebuffer driver. It was added to the default kernel for a while, then (probably rightfully) removed because it was added in a way that was hard to maintain older kernels.
<civodul>yeah that last sentence needs to be tweaked
<Haider>I have a LSP config in guix and whist using the clangd language server, I get this error whilst hovering over #include<iostream>: "In included file: expected ';' after class"
<Haider>This does not happen If I use the ccls server however. (yes I am using c++)
<devmsv>nckx: nothing. I will try again mirroring install.scm bootloader and kernel config
<nckx>When you boot the installer image, does it also spend a very long time displaying the GRUB background during boot? That's pretty, but here I think it indicates the same issue, that if the installer were to crash during boot it wouldn't be able to display errors.
<devmsv>Yeah it displays GRUB background for sometime. I start seen text of the boot in the middle of the process
<nckx>Probably after the initrd loads extra modules.
<nckx>Meh, I need to find a way to get Coreboot FB support back in new kernels in a way that doesn't break old ones. This is unacceptable. We're punishing people who don't use (wholly) proprietary BIOSes.
<devmsv>I'm my laptop with efi coreboot it works perfectly. But on this Chromebooks the only thing supported is seabios
<devmsv>But how can the installer boot and not the installed system? Isn't there a workaround?
<nckx>I don't know either. I too would expect the installed system to boot if it's not overly customised.
<devmsv>Well now I'm trying to chroot from the USB to the installed system and chroot is segfaulting >.<
<ngz>Hmm, I think I spotted two bugs in "guix home import"
<balbi_>hi folks, got a question here: I couldn't seem to find `rustup' available in guix. I'm trying to package it up, but before moving forward is there a reason why it's not in guix other than "nobody sent a patch"?
<nckx>Is it useful on Guix? Does it encourage installing non-free software?
<balbi_>rustup is just a tool to manage rust toolchains
<balbi_>you can choose and install toolchains for different targets
<nckx>‘Manage’ is doing a lot of unexplained work in that sentence.
<nckx>Yes, I assumed it was a package manager for Rust, hence my questions above, sorry, should have been clear.
<nckx>So since it is a package manager, those are 2 reasons it might not be in Guix. ‘Not useful’ being relative, but the set of people able & willing to package things for Guix is the same set that doesn't care much for language-specific package managers.
<balbi_>nckx: it's not a package manager, though. It's a toolchain manager. It allows you to setup toolchain for e.g. aarch64-unknown-linux-musl and have cargo use it
<balbi_>cargo is more of a package manager, and that's already in guix
<nckx>s/package/toolchain/ is a bit pedantic, but fine. Substitute everything I said above with toolchain manager if it helps. Everything applies.
<nckx>I was just guessing at possible reasons to begin with.
<balbi_>nckx: the real question though: if I were to send a patch, would it be acceptable by guix? Or is there a hard rule that would prevent its inclusion?
<nckx>No, wait, it's just a package manager: ‘Rustup installs The Rust Programming Language from the official release channels, enabling you to easily switch between stable, beta, and nightly compilers and keep them updated. It makes cross-compiling simpler with binary builds of the standard library for common platforms.’
<balbi_>nckx: yeah, just the toolchain :) you can't install e.g. ripgrep or bat with rustup
<balbi_>nckx: it was sort of a joke, yeah... but since you asked ;)
<nckx>It could suggest zomg-faster-nonfree-linker or icky-proprietary-runtime, I dunno.
<nckx>The thing being Free doesn't mean it only downloads Free things.
<balbi_>nckx: as of now, it only downloads upstream rust toolchains. AFAICT, there's a single implementation of the rust language. Perhaps we reconsider rustup's suggestions of non-free SW if we ever come to that?
<balbi_>nckx: no worries :) didn't take it as an accusation :)
<balbi_>anyway, next question. rustup wants a very specific version of rust-home, in fact its Cargo.toml points to a very specific commit of the repository. This means that during build phase, cargo will try to fetch that git repository, which doesn't appear to be allowed during build. Is there a way around that? I'm assuming the only solution would be package that particular version of rust-home and patch Cargo.toml before build phase to refer
<balbi_>to that packaged version. Is that the right approach?
<maximed_>Also, do you have some more context for "fatal error: avr/io.h"? It doesn't look like an error message from GCC, IIRC GCC would say something like "header <foobar> not found in directories X, Y, Z, W ... included from A B C D ..."
<fnstudio>maximed_: avr-toolchain is installed, the env var is empty
<maximed_>fnstudio_: Try logging in and out again (environment variables cannot be defined retroactively)
<maximed_>Alternatively, instead of installing avr-toolchain and friends, you can work with "guix shell --pure avr-toolchain other-stuff ..." (the --pure avoids potential interference from stuff in ~/.guix-profile, like, say, non-avr libraries)
<fnstudio>ah... interesting re the env var and logging in/out, let me try that
<maximed_>If that doesn't work, I suggest working in a pure environment (using guix shell or the like), to reduce the number of variables that might cause problems
<maximed_>hm, seems like "fatal error" comes from GCC anyway, seems like I misremembered
<fnstudio>yeah... with regard to guix shell that's what i usually do... but... i was worried that could be get in the way of my python virtual environment (as i said, after a first failed attempt at building everything, i thought of going for installing qmk from pypi)
<fnstudio>do you think i can still try guix shell even if using a python venv?
<maximed_>fnstudio: "python venv" probably uses environment variables, so probably not, unless you do the python venv stuff inside guix shell
<maximed_>though I'd think that using yet another package manager (pypi) would make things more complicated, not less
<fnstudio>yeah i totally agree re the venv; in fact, i was right in the middle of trying and building everything in guix
<fnstudio>so, i'll first sort the qmk stuff out, by creating the guix definitions
<fnstudio>then i'll try debugging the issue with the avr missing library, possibly trying the pure shell to see if that sets the env var that you mentioned
<fnstudio>i'll keep you posted if i see you around
<f1refly>I use an uncommon layout, but my girlfriend will share the machine for the next weeks and she needs a standard layout. So I'd need to have qwertz system wide, but something else for only my own user
<euandreh>IIUC, Guix the package manager runs on Raspberry Pi (ARM), but Guix System doesn't. Is that right?
<civodul>euandreh: the problem is that each ARM box has its own boot method, unlike PCs
<civodul>there are definitions for various boards, but i'm not sure about this one
<ngz>civodul: According to the Guile manual "there is no support for “non-greedy” variants of ‘*’, ‘+’ or ‘?’.". So I guess the answer is "no". Hmmmm…
<f1refly>or would I just set the layout in my X initialization script on login?
<civodul>ngz: ah, but actually, do you have an example string where the current regexp would fail?
<euandreh>civodul: ack, I'll go after some more info on that
<ngz>civodul: Certainly: alias ls='ls --color=auto'
<civodul>euandreh: you can check under (gnu system images *)
<civodul>ngz: i think that's fine, that's what the new test in tests/home-import.scm checks