<henrytill>hello, using guix as package manager on debian here, doing a periodic guix gc ritual. question: will running 'guix gc' as a non-root user also delete dead gc roots for the root user or should i also run 'sudo -i guix gc' to do that?
<futurile>is it just me or are Rust crate's dependency chains a nightmare? I'm building about the 60th crate at the moment - about 5 days of work so far - for one simple app. What's the emoji for simultaneously laughing and crying?!
<attila_lendvai>unmatched-paren, i'm not sure you're right thinking that. are you sure? i have two of these, and one seems to run judging from the output of guix reconfigure, but its name is not listed in herd status
<attila_lendvai>unmatched-paren, ok, i found my issue, it was in my code in the gexp. but the original question remains valid, although less interesting: my simgple-service instances don't show up in herd status
<mirai>attila_lendvai: they don't show because they're not __shepherd__ services
<mirai>only shepherd services will show with herd status
<attila_lendvai>mirai, yeah, the guix/shepherd service nomenclature always confused the hell out of me...
<mirai>and I'd be careful with how activation-service-type is used
<mirai>that thing does not take into account ordering or dependencies
<mirai>it's purpose is to run things after a reconfigure or at "boot time"
<attila_lendvai>the word 'service' is used both in guix and in shepherd, and they mix in a very confusing way in the code where both are present
<mirai>I suggest using one-shot herd services when possible
<attila_lendvai>mirai, that is perfect for my use-case here (see guix-devel with my mail a couple of minutes ago)
<attila_lendvai>mirai, that's what i tried first, but the trouble is, i couldn't construct an "inline" singleton shepherd service in the 'services field of my operating-system record. googling around i found this solution.
<mirai>unless that file or path is guaranteed to exist and get mounted at boot / before activation-service fires, that thing will cause hard-to-diagnose bugs such as #57589 (incidentally, the fix at #60756 is still waiting for a review)
<bonz060`>footlong: I was heading there. So no more -N. I'm running the container with guix as a package manager on a foreign distro and the above does not work. In fact, I have the following: http://ix.io/4nDL and I get the error: http://ix.io/4nDM without having "--share=/path/to/hosts=/etc/hosts"
<mirai>is there any value in keeping systemd .service / .target files in packages?
<cdegroot>Maybe for those that use Guix on top of a regular distro? It's how I use Guix and I must say, I can't recall having used included unit files but then, I was probably not aware of them existing (my go-to example would be Syncthing, which I run as a user-level service on all my machines)
<janneke>i've always wondered about config.site files and the speed increase they could yield, but never seen them used
<unwox>acrow: i want to write a package for a program that depends on guix
<jlicht>unwox: If this is for creating a guix subcommand (`guix mything ...'), check out how gwl does it (via GUIX_EXTENSIONS_PATH). If not, nvm :)
<HexMachina>Hi guix! I know packages are available for different architectures, but are the cross-compilers themselves availabke as regulary packages? I'd like to run e.g. arm-linux-gnueabi-gcc on my x86_64 host
<unwox>jlicht: thanks for the advice. it's not for a subcommand but i'll take a look anyway
<unwox>it'd be great to have "lib" output for the guix package i think
<gabber>HexMachina: no, they are specified to the `guix build` command
<gabber>nb: guix can build in VMs as well as cross compile (--target vs --system IIRC)
<HexMachina>I have software that needs to be compiled with arm-linux-gnueabi-gcc to produce an arm binary. I have that cross-compiler on my host distro but my host is old and guix generally has much newer packages
<HexMachina>(I'm running a foreign distro with an Ubuntu 18.04 host)
<HexMachina>the software I'm building is company internal and doesn't use guix at all. I'm just one developer trying to use guix to improve my workflow
<HexMachina>I was hoping to just be able to "guix install gcc-arm" or some such and use the guix cross-compile directly in the project's existing Makefiles
<gabber>HexMachina: that's the beautiful part, you don't need to! you can simply run `guix build mydesiredpackage --target arm` and have guix do the magic (or --system or aarch64, but i guess you get the hang of it)
<HexMachina>I'm not trying (or able) to package this software for guix
<gabber>so, IIRC the `gcc-toolchain` is the right package for you
<gabber>this should contain all the (cross-compiling) binaries you need
<HexMachina>it appears that gcc-toolchain only installs compiler/tools for my host arch - is there a way to install gcc-toolchain BUILT FOR x86_64 but TARGETING arm-linux-gnueabi ?
<HexMachina>guix must have these compilers somewhere, b/c it can build packages for other architectures, but they don't seem (easily) user-exposed
<HexMachina>judging from the packages guix tries to download in order to accomplish "guix build whois --target=arm-linux-gnueabihf", the packages I want are binutils-cross-arm-linux-gnueabihf and gcc-cross-arm-linux-gnueabihf, but I can't just "guix shell" those packages - are they hidden?
<HexMachina>and if so is there an easy syntax to use guix shell to install a hidden package?
<unmatched-paren>yes, those packages are hidden, and i don't think there's an easy way to install them
<apteryx>zimoun: if you're using systemd, 'systemctl stop gnu.mount guix-daemon'
<apteryx>or is it gnu-store.mnt? I can never remember
<zimoun>thanks, I am going to try… and report back. The office of my colleague is far so stay tuned. ;-)
<zimoun>apteryx, unmatched-paren: thanks. Well, removing and re-installing does not fix my colleague issue. It is weird, yesterday they installed Galaxy (webapp for bioinfo stuff) and now basically Guix communication with the outside world is broken; substitutes and even “--no-substitutes” is not able to fetch upstream sources.
<zimoun>well, this Galaxy had probably modified something somewhere but it is difficult to know what. Hum?!
<Hmmf>hah, it's not the worst. I really think I can make do with what is available.
<Hmmf>Oh btw, I don't use Windows but is it usable there?
<Hmmf>I don't even know how they do virtualisation.
<mfg[m]>Pretty sure it should work in WSL. Native Windows is not a thing.
<Hmmf>Oh yes they have that thing now. Oh well, I can always point people towards that.
<puddinghead>I'm considering to install Guix on top of a fresh reinstall of Debian soon, are there any packages you would NOT recommend me to get from Guix but from my distro's native package manger's binaries instead?
<mfg[m]>I'm not using Debian, but Arch. The only package i don't get from Guix is X and that's more because i couldn't figure out at the time i set things up how it works otherwise. For example when compiling something for Arch i always first run guix shell --pure -E 'XDG*' -E 'TERM' -- /bin/bash -l to get a shell without Guixy things.
<mfg[m]>Otherwise my gcc-toolchain from guix interferes with the hosts gcc
<mfg[m]>and that sometimes leads to weird c++ STL errors
<mfg[m]>especially when these gcc have different versions...
<Hmmf>All right. I have read a fair bit of the documentation and I am ready to dive into this (I wasn't reading the right doc actually, the Cookbook is the meaty one). Is there somewhere I can find example system declarations? Just something to get my feet wet. I will probably end up not using the gnu module and that seems to be quite a bit of work. Well
<Hmmf>I am not afraid of the work but I am not sure where to start.
<jpoiret>mfg[m]: I don't think `guix shell --pure` is a good idea in general for this purpose, it doesn't guarantee the subprocess to have your distro's default env variables
<Hmmf>Namely, I wish to configure the kernel as I see fit and remove quite a few things from the default installation (sudo comes to my mind).
<mfg[m]>jpoiret that's why i use bash -l in there my guix config is only configured for zsh
<Hmmf>Or, differently put, how do you do LFS with guix tools.
<jpoiret>Hmmf: you can easily remove sudo from the default configuration
<jpoiret>you have to remove the package from the default package list as well as its entry in setuid-programs
<mfg[m]>jpoiret: this is the env inside that guix environemnt: https://paste.debian.net/1270313/ seems pretty good to me, besides the fact that setting -E 'TERM' seems to also capture TERMINFO_DIRS that's the only var i don't expect there