IRC channel logs
2024-08-20.log
back to list of logs
<rynn>Well, the last bit of the log, the full thing is way too large for pastebin. <Kabouik>Guix can install packages (or run shells) for different architectures, liek dpkg --add-architecture but on a per-package basis instead of a dpkg tw toggle? <jfred>Kabouik: 'guix shell --system=i686-linux hello' <jfred>though substitute availability may vary <jfred>--system=aarch64-linux even works on an x86_64 machine through qemu emulation if you have qemu-binfmt-service-type enabled <jfred>(though note that's fairly slow) <Guest45>What am I doing wrong that I can't download from substitute mirrors? I'm attempting to download from the US mirror because I only average ~30kB/s on the official mirrors, but every package fails claiming they are not found, even though guix pull --substitute-urls=https://bordeaux-us-east-mirror.cbaines.net/ worked. I also tried the other <sepeth>rynn: maybe try setting PYTHONVERBOSE as suggested? <Atram>Hi, I tried to use a guile package (guile-irregex) in my system configuration. But `sudo guix system reconfigure' command returns the expected `no code for module (rx irregex)'. Is it simply a bad idea to use a strange guile module to create the configuration? Or, is there any way to make it work? <Rutherther>Atram: So do you currently have the module available through your GUILE_LOAD_PATH? <Atram>Yes, I use `guix shell guile guile-irregex' and I can use it in guile. <Atram>Rutherther: For some reason that I do not understand I need to pass the flag '-L /gnu/store/***-profile/share/guile/site/3.0', but GUILE_LOAD_PATH is correct. <Rutherther>Maybe its because with sudo the path is not passed to root's environment. But I am not completely sure <civodul>a day with broken Magit is like a rainy day <Kabouik>Thank you jfred! I am actually after using --system=x86_64-linux (or whatever it's called) on an aarch64 machine. Will try. <nckx>Atram: Does using ‘sudo -E’ improve matters at all? <nckx>I always forget whether or not vanilla Guix System defaults to -E, or not. <Rutherther>civodul thats broken for quite some time, must be a lot of rainy days :D <Rutherther>The fix for that is to override transient's #:emacs to emacs, to force native comp <Franciman>does my guix deserve an update today? Seems like a good day <Rutherther>The issue is that transient is loaded by loading elc first, and its the one from emacs itself, being too old version for magit <Franciman>is there any functionality difference or addition in guix master wrt guix 1.4.0? <jpoiret>1.4.0 is more than a year old at this point <jpoiret>point releases are *not* stable releases, guix is intended to be rolling-release and users should follow master <jpoiret>in other news: our udev uses libkmod which doesn't use our modprobe wrapper, so modules loaded by udev will not respect options in /etc/modprobe.d/ <jpoiret>wrt. what's new, you can read the news using `guix pull -N` <dariqq>is icedove failing to build right now? Or is it just me? <jonsger>dariqq: icedove@115 is broken, you need to switch to icedove-minimal or icedove-wayland... <dariqq>jonsger: the minimal version works. Thanks :) <jpoiret>isn't icedove-wayland just a wrapper over icedove? <jpoiret>if not that's a waste of cycles, since it's just a matter of env variables, no? <jonsger>jpoiret: it's a wrapper. It used to be around icedove, but now its around icedove-minimal. As the first is broken... <dariqq>jonsger: looking at build log for icecat-l10n the same errors occur as in icedove-l10n. But these are ignored (invoked with system* instead of invoke in make-l10n-package). Maybe need to do the same thing with the newer icedove? <jonsger>dariqq: if you want, you could create a patch with this change <dariqq>jonsger: It built successfully and i can choose different languages now. But something is not working correctly with the translations <civodul>i vaguely remember ensuring that this would work <jpoiret>I can look into it a bit more but that's my first impression <jonsger>dariqq: maybe the need to get updated <civodul>we set /proc/sys/kernel/modprobe, though i’m not sure if libkmod uses that <jpoiret>modprobe is from kmod, so there's no reason libkmod would use an executable from elsewhere <jpoiret>I did not check for sure that it's the case but it would be weird <jpoiret>and in any case it would only call the #$output "/bin/modprobe" not the global wrapper <civodul>oh but no, look, there kmod-module-directory.patch <jpoiret>yeah but nothing about the config directories <jpoiret>yeah, i'll try doing that at some point :) <jpoiret>btw, is there a thread on the current status of core-updates? <jpoiret>I've been running it for a while now, and just rebased again on master <civodul>no, i’ve suggested that we should send an update to guix-devel <jpoiret>I could find some time this week maybe <jpoiret>i'm doing lots of code these days for work so I haven't found some time to do any non-trivial Guix stuff <jpoiret>(apart from fixing stuff that breaks on my own machine) <jpoiret>civodul: is the consensus these days on merging or rebasing? <rynn>sepeth: I'll give that a shot, didn't see that previously <dariqq>jonsger: Also even in the minimal version it calls itself 'Daily' instead of thunderbird/icedove. ( see Settings > General). I dont really know much how thunderbird works internally <podiki>speaking of rebasing, i wanted to start on mesa-updates; should i rename the branch wip-mesa-updates if it will be rebased? <podiki>or do we just expect rebasing for non "wip" branches now? <podiki>(and i guess that means deleting and recreating on savannah since we can't force push?) <rekado>I'm using core-updates on aarch64 and x86_64, but "guix deploy" doesn't work for i686-linux (because of a failure to link guile-static) <rekado>(I opened issue #72725 for that) <civodul>rekado: oh thanks, i can take a look <peterpolidoro>hi. does anyone have any ideas why a package with libglvnd and mesa inputs would be able to compile but not find OpenGL at runtime? <Rutherther>peterpolidoro could you send exact message? Someone here had same issue few days ago and it seems cmake is too old to correctly locate opengl. <Rutherther>Its patched in some of the packages in guix, as in, the exact path is passed to cmake <peterpolidoro>I am trying to update the kicad package from version 7 to version 8. In order to get version 8 to compile, I had to add libglvnd. It seems to compile correctly, but when running kicad it gives me an error that says it cannot use OpenGL. I am assuming it just cannot find it. If it compiles does that mean cmake finds it? I do not know why kicad <peterpolidoro>kicad version 7 finds OpenGL. I do not know if the issue is with kicad, guix, or my debian base. <Rutherther>peterpolidoro oh, if there were no issues during confogure/build, then its something different <Kabouik>"while setting up the build environment: a `x86_64-linux' is required to build `/gnu/store/qvbq1b2pfjp0ka0kb0l3g264vimny30n-bash-minimal-5.1.16.drv', but I am a `aarch64-linux'" Does that mean I cannot use `guix shell --system=x86_64-linux` on an aarch64 platform? All my hopes just vanished. <char>Hello everyone. Does anyone have zhuyin input working on gnome on guix system? I have ibus-libpinyin installed. I can see libbopomofo settings in dconf editor under ibus-libpinyin but not under keyboard IME settings. I cannot find how to switch to zhuyin. <char>Of course I find it out right after I ask the IRC. I had to reboot, and the input is called Chinese (bopomofo) which is a totally separate input method as intelligent pinyin. <nckx>Kabouik: Are you *sure* that your qemu-binfmt-type is correctly configured? <Rutherther>Also another possibility is cross compilation. If you set up binfmt, dont forget to reboot <nckx>And to buy plenty of coffee and some long films if you want to build anything of substance locally. <nckx>Cross-compilation will be much faster at the expense of more bugs & fewer supported packages. <jfred>I wonder if we could get box64/box86 working via binfmt_misc in guix <nckx>(Or maybe it's not clear that --system means build on a virtualised x86_64 and isn't the same as cross-compiling with --target.) <nikolar>nckx: was cross compilation considered instead of native builds for aarch64 for example <Rutherther>But I would think that if you use x86 64 native via binfmt, it should be substituted, or is that not so? <nckx>nikolar: Like as 'the' aarch64 distribution? Not AFAIK. <nckx>Rutherther: It really is fully transparent, the hashes are the same all the way down and the builds think that they're running on a real x86 system. <nikolar>i ask because there's relatively little native arm compute for the build farm <nckx>I haven't thought about it deeply but I think that would actually be quite complex as soon as you go beyond 'guix system image'. <Rutherther>Also keep in mind that for the users to get anything substituted they would have to also use cross compilation.That will mean necessity to have x86 64 machine, since you always need to build at least something, you cannot substitute whole system - you have etc, /run/current-system, and such <Rutherther>Or not necessarily a machine, but the binfmt enabled <nckx>nikolar: Just complex as in fragile, tedious, but admittedly not undoable. Maybe you can add --system=x86_64-linux --target=aarch64, and make sure you've always got an x86_64-linux box connected, I've not tried. <nckx>This is not something the project ever recommended as plan A though, and we never served cross-substitutes at that scale AFAIK. <nckx>I think "technology preview" was the settled-upon euphemism for now :o) <nikolar>i assume there are no builders then heh <peterpolidoro>could gpu drivers affect a program's ability to use OpenGL? gpu drivers are not included as package inputs, but could a Guix program fail to use OpenGL if it depends on gpu drivers that are managed by the host operating system? <podiki>peterpolidoro: if you mean guix on a foreign distro, probably guix won't load them, correct <podiki>libglvnd should be able to handle such a thing, but not sure how that works exactly. and we should enable it in our mesa (it is not, i don't think), as probably that's how to best deal with on foreign distros <podiki>just my guess, as guix won't know about host system stuff. maybe with some LD_LIBRARY_PATH or GL path env? <peterpolidoro>yes on a foreign distro. so gpu drivers are a dependency of OpenGL that is not captured by Guix inputs? I am including libglvnd and mesa as package inputs but I do not know if they need to know about the host gpu drivers or how it finds them <Rutherther>Its quite hard to make drivers declarative like this. Though I dont know the exact state for guix, this is also not solved for nixos. There are only workarounds that load the drivers properly upon runtime <peterpolidoro>so is there any reason why this would work properly for some packages and not others? <podiki>you might want to check the various GL path env variables. that can tell mesa where to find drivers <podiki>though might run into compatibility issues <podiki>just a guess. but yeah, it is like running a containerized thing sort of. <podiki>(should be possible, just don't know the details of how or if things can without other changes to how things are currently configured/built) <nckx>nikolar: My knowledge was out of date; we do cross-compile (presumably all) packages 'from x86_64-linux to i586-pc-gnu, aarch64-linux-gnu and arm-linux-gnueabihf' on bordeaux. <nckx>That said, many packages don't cross-compile in practice, and whole build systems don't support it at all. <nikolar>because for the most part, the aarch64 builders are constantly active while x86 aren't so i assumed there wasn't much cross building going on <peterpolidoro>did something change in Guix that required libglvnd to be added as a package input for OpenGL? I am just trying to update a package version. The previous package version just needed mesa as an input but the new package version seems to need libglvnd as well in order to compile. The old version uses OpenGL properly during runtime but the new version <peterpolidoro>does not. Do I need to add an environment variable to make libglvnd work properly? <jfred>those aarch64 builders are quite behind (as I've discovered recently trying to apply my home config on my aarch64 laptop, heh) <Franciman>are you people able to use other distros after guix? <Franciman>not to mention how easy it is to package thigns <ieure>I'm still daily-driving Debian, as there are several things missing from Guix which I need. <jfred>Franciman: with some annoyance, yes - though I do tend to install guix on them regardless ;P <ieure>I agree that `guix shell' and the ease of packaging (and of running your own channel) are very nice vs. other distros. <Franciman>do you have other killer features of guix that you love and miss from other distros? <Kabouik>nckx: I am definitely not sure that qemu-binfmt-type is correctly configured. How do I do that on a foreigh distro? <jfred>Franciman: easy rollbacks if you mess something up is the big one <Rutherther>Kabouik probably will be easiest to follow your distro instructions to enable it <ieure>Agreed that rolling back the system is awesome. <jfred>the system and your home config if you use 'guix home' <jfred>(well, that one you can get on other distros. with guix :P) <jfred>and I do, the machine I'm on now is ubuntu (not by choice) but I'm running pipewire and friends from guix as home services <nckx>Kabouik: Not something with which I can help you. You might have to write your own service, but IIRC the meat is echoing something to sysfs. <nckx>Read the service, it mentions some stuff shipped with qemu itself that might be aimed at FHS distributions. <nikolar>to be fair, easy rollbacks are easy to get with zfs/btrfs on any distro <nckx>It seems like such a cool hack than I'd expect all distributions to pounce on it, so Rutherther is right, check there first. <Kabouik>You see a cool hack but I admit it is not as straightforward as I was hoping for (i.e., run `guix shell --system=x86_64-linux wine64`, ????, profit). <Kabouik>But thanks Rutherther and nckx for the answers! I'll read it and see what's my best option. <nckx>It's a one-time investment to make than command work but I understand. <pi`>Is it correct that only system installed emacs packages show up in the loadpath of Emacs while profile emacs packages are only available in guix shell? <Kabouik>nckx: es, definitely worth it, I'm just plaing cautious because I see some `dpkg --add-architecture` in Debian's manuals and that means potential system clutter/complicated updates, and significant disk use, all being potential issues on my platform since it's mobile and alpha-state (so even regular updates are sometimes *interesting*). I have to read it all. <dariqq>pi`: the search path is "attached" to emacs. So if you want to have emacs packages in multiple profiles youll need to have an emacs in each one (also true for python, guile, etc) <Kabouik>Sorry for the typos in the above message by the way, my keyboard is not cooperating. <pi`>dariqq: Thanks, I was missing emacs in the profile <weary-traveler>when generating a docker image via guix pack, is there a way to include something like the output of "guix describe" in the generated image? <graywolf>Hm so I am having "interesting" issue. I am usually reconfiguring my system as `sudo guix system reconfigure -L . some/config.scm'. However when I tried today, it no longer works. I think I nailed it down to wrong load-path. When I do `guix system reconfigure -e '(pk %load-path)'' I get different path then when running the same with sudo. <graywolf>Should they be the same? If not, what could be the cause? Any ideas? <graywolf>(Ah, when I run it on one Guix server, both sudo and non-sudo paths are same. So now just to figure out the cause...) <graywolf>Actually ignore that, they are not the same, I am dumb. <graywolf>Oh this is interesting. So when I run guix system build, my home guile modules are available: /home/wolf/.guix-home/profile/share/guile/site/3.0 . When I run sudo guix system build, they are not. <graywolf>How the hell am I supposed to reconfigure my system now... I can *build* is just fine (no sudo required), but cannot reconfigure it. <graywolf>Will two-phase attempt work (1. Install the guile module I need as a system-wide package 2. Reconfigure 3. Start using it in my system configuration)? <graywolf>Or should I just GUILE_LOAD_PATH it? Not sure how to handle it <jfred>yeah was just about to say, sudo -E might do it <graywolf>uh, sudo -E does work. Not sure if it will break anything those, documentatin does not use the -E flag :/ <peterpolidoro>I am trying to compile the latest version of kicad and am getting OpenGL compilation errors like "error: ‘GLUtesselator’ was not declared in this scope". Included in the package inputs are libglvnd, mesa, and freeglut. Am I missing another package input or could it be another problem?