IRC channel logs
2023-02-10.log
back to list of logs
<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? <ngz>mvnx: first message has to be approved by a human. It may take a few hours, at most a couple of days. <ngz>henrytill: guix gc will only delete roots for your user. Note that bare "guix gc" is a bit zealous. You may want to use --delete-generations option. <reb1>I have a question regarding the gcc-toolchain is this the right place? <reb1>ok. I'm trying to create a package with glibc 2.29. <reb1>using make-gcc-toolchain <reb1>I create the function (which returns a package) but then I cant use this package in a regular manifest. <reb1>any ideas?. I can paste the code if you want. <Guest46>sure paste the code, maybe it helps someone. I don't know, do not have the experience to help you <reb1>(use-modules (guix packages) <reb1> (gnu packages commencement) <reb1>(define my-gcc-glibc-2.29 <reb1> (make-gcc-toolchain gcc glibc-2.29)) <reb1>This is the code in a manifest.scm file. <lechner>it would be better to use a pastebin service, if you have one <reb1>thanks. I'm unfamiliar with the process I will take note of that. <oriansj>we really need to add a notes for new people link <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>my issue is that it doesn't seem to be run, or at least i don't see neither the sideffect, nor any errors in the logs <zimoun>some issue with the build farm? An user here has some issues: guix is stalled when fetching substitutes. <unmatched-paren>attila_lendvai: it should be in ``herd status'' under ``my-service'', yes <mfg[m]>How do i reference the output dir to introduce some symlinks after the install phase? it seem #$output is not the actual directory that guix build would return. <andreas-e>@zimoun I just tried to install a new package, and am downloading packages happily from bordeaux. This is the first entry in my --substitute-urls, and I suppose they are tried in order? <zimoun>andreas-e: thanks. So maybe a “bug between the chair and the keyboard“. ;-) I will go to check with the user here. <andreas-e>It could still be a bug with berlin if the user has not authorised bordeaux. <BitPuffin>hmm guix installed raco pkg install fails with SSL checks, not sure if I should suspect guix or raco <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, no, they have distinct names. i used 'my-service here for added clarity <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>I am confident that if the purpose is to emulate /etc/tmpfiles then it absolutely isn't <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) <anvo>After qemu-system-x86_64 -m 1024 -smp 1 -enable-kvm -nic user,model=virtio-net-pci -boot menu=on,order=d -drive file=guix-system.img -drive media=cdrom, file=/home/anvo/Downloads/guix-system-install-1.4.0.x86_64-linux.iso <anvo>I get qemu-system-x86_64: file=/home/anvo/Downloads/guix-system-install-1.4.0.x86_64-linux.iso: drive with bus=0, unit=0 (index=0) exists <anvo>Guyz! Qemu says "drive with bus=0, unit=0 (index=0) exists"! What do I do...? <jlicht>at the risk of (re)stating the obvious, we do not run tests in the check-phase when cross-compiling, right? <attila_lendvai>jlicht, i think the check phase is called, but with a #:tests? #f argument, which it should test for <jlicht>ah yeah, I see it now. Thanks attila_lendvai! <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) <mirai>right, I forgot about that usecase <unwox>what is the correct way to install guix as a library? IIUC adding it to propagated-inputs will also install guix command to user's profile which is undesirable <oceane>guix can't reconfigure itself from my config file with a backtrace and a big wall of text, did i do a common mistake? <gabber>hi! my `guix pull` fails due to a "platform-not-found-error target-or-system: \"aarch64-linux-gnueabihf\". i don't know where i had specified such a thing - i am on x86_64 <acrow>unwox: Not sure what you want but you can just download the source, fire up an instance of guile and issue: ,use (guix) (After modifying your GUILE_LOAD_PATH or moving the source there...) <wingo>what if guix shell could also create autoconf config.site files <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 <HexMachina>because I'd like to use guix for embedded develop on source that is not itself packaged by guix <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>the project is complicated and in one single Makefile it uses multiple compilers to compile the same source for multiple architectures <HexMachina>so I was hoping to just swap my host's gcc-arm for a newer one in guix <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 <unmatched-paren>maybe you could try using -e '(@@ (...) gcc-cross-arm-linux-gnueabihf)' or similar... <zimoun>How can I remove /gnu? “sudo rm -fr /gnu/store” fails because it is read-only and then I have tried many stuff (chattr etc.). <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?! <zimoun>nope, nothing work and I have tried many things. My guess is about Galaxy, it probably tweaked a config somewhere. Well, late Friday is not a good moment for debugging boring config. ;-) <mirai>how do I suspend to RAM / sleep from a terminal? <panosalevro>hi all, guix noob here. why cant i find `mpc` after installing it? <jlicht>panosalevro: what exactly are you missing? <panosalevro>jlicht: mpc itself apparently. it says command not found. but i have already done `guix install mpc` <rekado>is .guix-profile/bin on your PATH? <jlicht>panosalevro: so TIL, but `guix show mpc' describes a math library. Are you perhaps expecting something else that is also called mpc? <rekado>(that’s the tool to talk to mpd) <Lumine>mpc is a gcc library iirc, it can't be invoked directly from PATH <mfg[m]>mirai: are you searching for the zzz and Zzz (or ZZZ) programs? <panosalevro>pretty strange, i believe i always installed the mpd client when installing `mpc` on other distros. i had no idea about the mpc C library <Lumine>You're right, some distros have it as mpc-cli for example <Hmmf>Hello. I am looking forward replacing Docker and the such by guix. Is there some specific documentation about this? <Hmmf>I mean, I'd wish to spawn a bunch of guix systems in virtual machines. <Hmmf>Maybe it's just not a good idea. I vaguely remember a video I saw about spawning virtual machines from a guix definition. It even had orchestration if I remember well. <mfg[m]>Dunno about orchestration, but do you mean guix system vm? <Hmmf>But it's not really the *dream*. <jackhill>there's also guix deploy and guix system containers. I think all the building blocks are probably there, but you'd have to put them together yourself. <Hmmf>Damn that's exactly what I needed <Hmmf>Aight, I'll try to write something for my specific needs. It might be useful to others. <jackhill>the main obstacle for using more of the guix tooling for me is that some software is just a lot of work to package and that work is yet to be done <Hmmf>Well I understand that. I'm just worried about the guys I'm going to send these to. <Hmmf>Idk, getting rid of Docker is just a wet dream I always had since it became ubiquitous. <Hmmf>I tried guix back in the days to just replace my main OS. I am trying to get back to it for my development needs. <Hmmf>I hope it makes the transition easier. <jpoiret>there is absolutely 0 orchestration mechanism in guix right now though, just be warned <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 <jpoiret>oh, right! does that override the env variables that it is spawned with though? <jpoiret>if gcc-toolchain from Guix messes up arch, i'd suggest not having it installed globally <Hmmf>Because that's where the tooling comes from? Or is it just that the spectrum of what can be configured is somewhat limited? <Hmmf>Like, in the system definitions I see from the doc, quite a few packages seems to come "batteries included". <Hmmf>How do you get rid of these batteries? <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 <mfg[m]>so i should probably change that to -E '^TERM$' <jpoiret>seems like a good solution then :) you still have a GUIX_ENVIRONMENT around though <mfg[m]>yeah but guix tells me that this env is empty <jpoiret>tbh if things don't interact well with your distro if they're available from Guix all the time, they should be in a separate profile/used via guix shell <mfg[m]>well, yes. I think i have a new to-do for the weekend then :D Trying to understand why I did things like i did and probably changing it to the right thing™ <apteryx>I think IceCat/Icedove language pack add-ons will only be discovered when they live in the same output as the application... <apteryx>no fancy search path seems to be possible <apteryx>so perhaps what it'll look like in a first stage is that the current icedove would be renamed to icedove-minimal and the icedove with the localization data would be the new regular icedove. <jpoiret>apteryx: are you working on icedove currently? <jpoiret>I am updating it as M$ login doesn't work with the current version, it is building locally <civodul>roptat: hi! did you have a chance to draft a patch for the branching policy? :-)