IRC channel logs


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?
<mvnx>I tried posting to the help-guix mailing list for the first time a few hours ago but still don't see my message on Are screenshots rejected? Would I receive an email if there was an error submitting? Should I just wait longer?
<footlong>"help-guix (date)"
<ngz>mvnx: first message has to be approved by a human. It may take a few hours, at most a couple of days.
<lechner>we are working on ChatGPT
<mvnx>ngz: Great, thanks.
<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.
<henrytill>ngz: thanks and noted!
<reb1>I have a question regarding the gcc-toolchain is this the right place?
<Guest46>just ask the question
<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>ok thanks
<reb1>(use-modules (guix packages)
<reb1>         (gnu packages commencement)
<reb1>         (gnu packages gcc)
<reb1>             (gnu packages))
<reb1>(define my-gcc-glibc-2.29
<reb1>  (make-gcc-toolchain gcc glibc-2.29))
<lechner>you got muted
<reb1>This is the code in a manifest.scm file.
<lechner>it would be better to use a pastebin service, if you have one
<Guest46> can you paste it on that site
<footlong>"Debian Pastezone"
<reb1>thanks. I'm unfamiliar with the process I will take note of that.
<footlong>"debian Pastezone"
<oriansj>we really need to add a notes for new people link
<apteryx>it's in the topic
<sughosha>Hi, could someone take a look at
<footlong>"[PATCH 3/3] gnu: supertuxkart: Update to 1.4."
<futurile>morning guixers!
<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_>if i have a (simple-service 'my-service ...), then should it show up in `herd status`? if not, what can i do? it's something like this:
<footlong>"thomassgn/guixsd-configuration: Configuration files for GuixSD. - Free code hosting"
<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>hello guix :)
<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
<BitPuffin>for racket i mean
<BitPuffin>browser seems to think ssl is fine though
<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
<unmatched-paren>attila_lendvai: you're running herd status as root, right?
<attila_lendvai>unmatched-paren, yes
<BitPuffin>ah this helped though
<unmatched-paren>wait, do you have two services called 'my-service?
<BitPuffin>+ a space, as always rtfm I guess
<BitPuffin>shout out to guix manual contributors <3
<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)
<mirai>the special-file one?
<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.
<attila_lendvai>mirai, yes
<mirai>I am confident that if the purpose is to emulate /etc/tmpfiles then it absolutely isn't
<attila_lendvai>mirai, all i need is to write XHC into a file once every boot
<footlong>"Rethinking how service extensions work"
<attila_lendvai>mirai, thanks! i'll try to rewrite it based on that example
<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)
<footlong>"Guix hangs on GDM with Wayland"
<footlong>"[PATCH 0/2] Add x11-socket-directory-service-type."
<mirai>related discussion is
<footlong>"Expanding service procedure to accept additional arguments"
<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
<mirai>attila_lendvai: see how I'm adding a workaround for networking at
<footlong>"Untitled - Pastebin Service"
<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
<attila_lendvai>mirai, excellent! i'm busy making notes... :)
<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`>Hi guix!
<bonz060`>I just did a "guix pull" and the "-N" flag in the guix system container doesn't work. And this is relatively new (to me):
<footlong>"Container Networking (GNU Guix Cookbook)"
<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: and I get the error: 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
<gabber>full error log here:
<oceane>sure, here's my paste:
<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 files
<janneke>i've always wondered about 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>gabber: :(
<gabber>why? it's a feature, not a bug
<HexMachina>because I'd like to use guix for embedded develop on source that is not itself packaged by guix
<gabber>on what architecture?
<HexMachina>arm for starters
<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>ah ok! That sounds more like what I 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
<gabber>nothing holding you back (:
<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
<jgart[m]>bonz060`: maybe ask efraim:
<jgart[m]>bonz060`: try with this flag also:
<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.).
<footlong>"~whereiseveryone/nb: src/nb.lisp - sourcehut git"
<unmatched-paren>zimoun: you need to remount the store read-write iirc
<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?!
<unmatched-paren>zimoun: removing the store doesn't work?
<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?
<gnucode-on-the-h>morning guix people!
<jlicht>mirai: for me: loginctl suspend
<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>mpd-mpc perhaps
<rekado>(that’s the tool to talk to mpd)
<Lumine>mpc is a gcc library iirc, it can't be invoked directly from PATH
<panosalevro>oh wow. i was indeed looking for mpd-mpc
<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
<panosalevro>oh it's a gnu package. that explains it :)
<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>The only thing I found was that
<footlong>"Installing Guix in a VM (GNU Guix Reference Manual)"
<Hmmf>But it's not really the *dream*.
<mfg[m]>The documentation here may be what you are searching for?
<footlong>"Invoking guix system (GNU Guix Reference Manual)"
<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
<jlicht>prayer and Chimay ;)
<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
<unmatched-paren>Hmmf: not using the gnu module? that's impossible.
<jpoiret>oh, right! does that override the env variables that it is spawned with though?
<mfg[m]>hm, lemme see
<jpoiret>if gcc-toolchain from Guix messes up arch, i'd suggest not having it installed globally
<mfg[m]>never thought about that
<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: 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
<footlong>"debian Pastezone"
<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.
<apteryx>we'll see how big it is
<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? :-)