IRC channel logs
2025-01-31.log
back to list of logs
<eikcaz>sneek: later tell lockbox____: Ah, I should have read that fsf page more carefully. Seems like residential addresses are greylisted, not blacklisted, by gnu.org. And I already messaged guix-devel about it... (Sorry for the spam!) <eikcaz>is issues.guix.gnu.org down? I find it unlikely that the most resent issue is from 3 days ago. <coyotes4ys>oh guix has systemd? i didn't know that. i've seen people crying from rooftops about loss of freedoms for sysadmins and devs <apteryx>coyotes4ys: it doesn't (have systemd) <mange>Right. In a Guix context the word "channel" has another meaning. I don't know anywhere to chat about xrandr specifically, but #xorg might be appropriate? <coyotes4ys>oh the channel is like that huge long string after gnu/store? <mange>No, a channel is like an extension to Guix that can add extra functionality. Currently they mostly add packages, but there's a patch that's been submitted to allow them to add commands, too. <mange>So you can see why asking for "a channel for xrandr" is confusing. :) Particularly given xrandr is in the core Guix distribution, so shouldn't need a channel. <coyotes4ys>yes. it's unfortunate both things have the same name <coyotes4ys>if i can remember i'll purpose to use "irc channel" in this channel <coyotes4ys>unless it's obvious/not needed as in my previous line haha <meaty>Does anyone know what would cause me to get "No such file or directory" errors trying to run a binary that's explicitly in a guix shell command? <ieure>meaty, Binary likely references shared libraries it can't load. <meaty>i.e. 'guix shell wine -- wine' -> 'guix shell: error: wine: command not found' <ieure>meaty, Usually means the package isn't setting the rpath correct. Is this a problem with wine, or just an example? I pushed some wine patches a couple hours ago. <ieure>If those are busted, I'll revert them. <meaty>ieure: I think it's a problem with wine, I am on guix a488039 <meaty>I also cannot launch any of my windows games via lutris flatpak <ieure>meaty, That's before the commits I just pushed, so, thanks for reassuring me that I didn't break anything. <ieure>meaty, Can you paste the output of `guix shell binutils -- ldd $(which wine)' somewhere? <ieure>This is more for my curiosity / to show you how this works than to fix your problem. Hopefully if you `guix pull', wine will work for you. But you'll also likely end up compiling it, since I doubt the substitutes are ready yet. <meaty>ieure: your command was incorrect, binutils doesn't have ldd--regardless, `guix shell gcc-toolchain -- ldd /gnu/store/77xx06g1kfcglkjgh67226ng6jh03lkq-wine-9.0/bin/wine` -> "not a dynamic executable" <meaty>ldd should list all the .so files right? I test it with ldd `which ls` <ieure>meaty, Ah, probably means wine is a shell script. <meaty>ieure: but I can't 'less' it, it's a binary file <ieure>What does `guix shell file -- file $(which wine)' show? <ieure>podiki, Yeah, graft situation is pretty wild right now. <meaty>ieure: /gnu/store/77xx06g1kfcglkjgh67226ng6jh03lkq-wine-9.0/bin/wine: ELF 32-bit LSB pie executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /gnu/store/hw6g2kjayxnqi8rwpnmpraalxi0djkxc-glibc-2.39/lib/ld-linux.so.2, for GNU/Linux 3.2.0, stripped <ieure>Was thinking of sending patches that ungraft everything. But that'd build a ton of stuff, and last I heard, qa.guix wasn't working right. So I don't know how we'd even do something like ungrafting. <podiki>the "no such file or diretory" can also mean it didn't find the ldpreloader <podiki>but that shouldn't happen here (can reproduce on current commit with wine 10) <podiki>i think ludo had set up an ungrafting build job, not sure the status of it though <meaty>ieure: what's strange to be is that I'm running a 64-bit system, why did I receive a 32-bit executable <ieure>meaty, There are some bitness issues with Wine that I don't fully understand. <meaty>ieure: I guess i'll just pull and upgrade to see if that fixes it <podiki>meaty: i'm on the current commit <ieure>The path to the binary interpreter doesn't exist on my system. <ieure>ls: cannot access '/gnu/store/hw6g2kjayxnqi8rwpnmpraalxi0djkxc-glibc-2.39/lib/ld-linux.so.2': No such file or directory <ieure>podiki, You see the same thing? <meaty>my system is missing that file too <podiki>what did you do to get that output? i was confirming wine doesn't run with "no such file or directory" <ieure>podiki, `guix shell file -- file $(which wine)', that prints "interpreter /gnu/store/whatever". <ieure>The interpreter file doesn't exist on my system. <meaty>podiki: guix shell wine ... wine <ieure>Curious if you see the same or not, with the output from file on your system, not what I pasted. <meaty>ieure: yes, the interpreter is missing <ieure>It's consistently compiling funny. <ieure>Honestly surprised the package built, there's a whole phase to check this stuff. <podiki>what about wine64? (building locally, no sub) <podiki>the hash wasn't for glibc --system=i686-linux either <ieure>No wine64 binary in the package. <meaty>oh wow the graft situation *is* crazy <meaty>guix shell wine64 -- wine succeeds <ieure>99% sure I've successfully used `guix shell wine -- wine' to run stuff before. It was /critical/ that I play The Typing of the Dead, I tell ya <podiki>try a time-machine to wine 9 maybe? <ieure>Yeah.... probably want to do that in a git bisect to see where things went funny. <podiki>wine is explicitly the 32bit version but i can't remember what works/didn't before (i don't typically use wine directly, but i do think wine and wine64 both worked on x86_64 before) <Guest39>Can you suggest some minimalist and modular guix system configurations for inspiration <Guest39>or batteries included ones which I can just begin to use with minimal modification <Rutherther>Hey, does anyone use librewolf/firefox with native messaging hosts? Recently native messaging host stopped working for me in newer guix versions. When I obtain it from older guix, it works fine. So seems like a dependency broke it. ieure: any ideas? <Rutherther>(when I obtain it meaning librewolf, not the native messaging host) <ngz>Hello. Whenever I try to guix gc anything, I get "committing transaction: database or disk is full", and the process stops, in a vicious circle. Do you know how I can reclaim some space guix gc won’t give me back? <ngz>Ah. I now see issue 53000. <ngz>Indeed. Clearing /var/cache and /root/.cache gave me enough disk space to proceed. <ngz>Anyhow, when I called "guix shell" before all of this, it warned me 347 MB were necessary but only 100 MB were available in <ngz> /gnu/store, but started building the profile nonetheless. <ngz>I don’t think it should have. <ngz>(I interrupted manually the process, but it was too late) <jaadu>I have xterm installed with guix on a foreign distro. But the window lacks an icon. What can I do to get it back? <jaadu>Do I need to do some integration with dbus or something? <cancername_>Hi everyone! I'd like to use the copy build system's install step in the GNU build system. I tried (modify-phases (replace 'install (@@ (guix build copy-build-system) install))), but that didn't work because (@@ (guix build copy-build-system) install) says install is undefined, which is defined right at the top of the module. Why is that? <lilyp>cancername_: the way to write this is (assoc-ref copy-build-system:phases 'install) <lilyp>you probably don't even have the module, but even so, don't use @@ <lilyp>as for copy-build-system using it that way will still fail because of the missing #:install-plan <cancername_>lilyp: Yes, I see why @@ shouldn't be used. What do you mean, I don't have it? It's in /run/current-system/profile/share/guile/site/3.0/guix/build/copy-build-system.scm . <lilyp>unless you use it as build-system or declare it as in #:modules, it won't leak into the build environment <cancername_>lilyp: says copy-build-system:phases is unbound, whether in the package or build environment, with (guix build-system copy) and (guix build copy-build-system) used. <lilyp>my bad that's %standard-phases; and you have to use #:prefix to get the prefix :) <jaadu>cancername_: Is this something that has been added to the guix install scripts recently? <jaadu>I did my guix installation a few years ago and I have kept OS and guix profiles up to date. But I don't think the files that the guix installation script installed has ever been touched. Am I correct? <ekaitz>sneek: later tell efraim to ping me when he's available for a short talk <orahcio>Hi, another question about conda on guix, I could not run any conda binary. I need to emulate a fhs shell? <Rutherther>orahcio: need to is a strong word. It is one way to run randomly downloaded binaries <orahcio>Rutherther: There is another most pratical way on guix? <orahcio>Rutherther: but conda is a guix package, but if I can not use conda (because I can not run it binaries), why conda is a guix package? <Rutherther>I have no idea, that's question for the person who added it to guix <Rutherther>maybe conda can be convinced to use the system's python from PATH instead of custom binaries. And then you could use it only for packages, which can be fine unless they are using external libraries, where LD_LIBRARY_PATH can sometimes help <orahcio>Acctually the binnary form conda results not found file, the same error when we try to run random binnary, even python the base package from conda can not run, maybe conda package on guix need to run inside a fhs environment by default, I don't know if we already have some package on guix with this feature <Rutherther>orahcio: yes, it does, the dynamic linker is not at the path that is hardcoded in the file <orahcio>Rutherther: I could not understand, I can run or I can not run that binnary? Outside a fhs shell, I mean. <Rutherther>orahcio: 'that binary', no, but you could of course modify it to make it into a binary that will run, by patching its runpath and the dynamic linker path <orahcio>Rutherther: but how to make it on each conda package? I need to do it every binnary from conda? It seems a script to make conda packages to run. The fhs shell would be a more pratical way, or not? <Rutherther>orahcio: that depends on what you will be doing. Not every binary can run well in container <orahcio>Rutherther: I want use some packages from conda that I have not in guix, but even python package I can not use from conda, this is the start point. I want to start, but with conda now Ith seems very difficult <f5mg_is_firewall>Is it normal for Guix to do the full-source bootstrap as part of a `guix pull`? <cancername_>f5mg_is_firewall: check "guix weather" for that package and wait a bit <AwesomeAdam54321>cancername_: It looks good to me, but I'd change the package arguments to use gexps instead of quasiquote <f5mg_is_firewall>cancername_: the problem is I don't know exactly what it's building. Why would it need to do a bootstrap? <ieure>sneek, later tell tschilp I pushed a fix for pantalaimon, someone had sent a patch around a week ago. <vhns>Has anyone come up with a smart way to reload PATH whenever running sway and using guix-home? So far the only way my peanut brain has figure out is to logout and login. <vhns>(After running `guix home reconfigure`) <Rutherther>vhns: the only other way would be to add code to sway to update its environment variables. You cannot update environment variables of a running process unless the process does that by itself <Rutherther>since wayland is based around protocols using ipc, you can just make your own that would update it. Maybe there is a protocol like that already <f5mg_is_firewall>2 hours later, it's still doing the full source bootstrap for no apparent reason... <f5mg_firewalled>I don't know who to tell this to, or how to write a mail about it without coming off like a jerk, but: <f5mg_firewalled>If you're going to modify an important variable like `%base-packages`, please at least write a news entry about it <f5mg_firewalled>So the rest of us aren't left scratching our heads over the 'multiple version of $PACKAGE in your profile' error when we `guix system reconfigure` <ekaitz>f5mg_firewalled: you came out like a jerk anyways, but it's all good, we understand the frustration <ekaitz>f5mg_firewalled: could you provide more info about which package that was? <pegaso>what's the best amd apu i can get that will run on linux libre? I'm trying to assemble a guix box... <pegaso>what do people here run usually? <pegaso>I want to build something future proof <f5mg_firewalled>ekaitz: drat. I really should watch what I post when I'm hours deep into debugging arcane issues... sorry about that <ekaitz>f5mg_firewalled: that's right in my birthday LOL <ekaitz>f5mg_firewalled: don't worry, frustration is understood here <f5mg_firewalled>Ok, basic question. If I change the 'guix' channel to point to my local clone, Guix should still be able to find substitutes for everything, right? <ieure>f5mg_firewalled, Yes, though if you change any packages in your local fork, those won't have substitutes. <Rutherther>ieure: hi. Any idea why native messaging host stopped working in librewolf/firefox recently? I've tried earlier version of guix channel and it works fine <Rutherther>or any idea on how to debug it? Librewolf doesn't seem to handle a lot of information about errors concerning native messaging hosts, just one generic error <Rutherther>f5mg_firewalled: every package has a hash according to its build script and its dependencies. This is what substituting is looking for. So apart from the packages you change directly, expect also local builds for packages changed indirectly by changing their dependencies <f5mg_firewalled>ieure, Rutherther: right, makes sense. So now I need to figure out why pulling from the 'build' branch of my fork, which only touches Makefile.am, doc/ and guix/scripts/, suddenly needs Guix to bootstrap literally everything starting from mesboot0 <f5mg_firewalled>I changed the channel url in .guix-channel. Would /that/ affect anything? <ieure>Rutherther, I don't even know what "native messaging" is. Like when websites want to send you notifications? <Rutherther>ieure: no. It's for extensions to communicate with outside of the sandbox. For example tridactyl extension uses it to access rc file in home directory, or browserpass uses it to access password store from the disk <Rutherther>f5mg_firewalled: are you sure you're on a commit that has been built by CI? <ieure>s/private channel/personal channel/ <ieure>Obvs it is not private since I just linked you there. <Rutherther>ieure: sure I cant give it a spin, but I am a bit afraid something in the dependencies must've triggered breakage, I also have Firefox 134 and there it also doesn't work <f5mg_firewalled>Rutherther: my branch starts from the master branch at b85d20e853. I could `guix pull` from the master branch (of my fork) just fine, so I'm assuming substitutes were built for that commit <ieure>f5mg_firewalled, Might be worth a guix-devel post. <Rutherther>f5mg_firewalled: what do you mean by 'could pull just fine'? you can pull from any commit, no matter if CI built it or not <f5mg_firewalled>Rutherther: I mean it found substitutes for stuff, as opposed to the current issue where it's trying to build X-mesboot0 from source <Rutherther>f5mg_firewalled: okay, if the pull got hit on substitutes for the guix package itself, then indeed, that commit must've been built by CI <ieure>Rutherther, Most of the browser's deps are vendored, which, while not ideal, makes it much more resistant to breaking due to dep changes. So this might be an upstream thing. <fanquake>Before I go look at the docs, is there an obvious reason why "guix shell --container gcc-toolchain" gives me GCC 14.2.0 <ieure>I'd like to unbundle things, but with direct dependencies of it in the many dozens to low hundreds of Rust libraries, and who even knows how many transitive deps, it's a very difficult prospect. <fanquake>but "guix shell --container -m manifest.scm" (where manifest.scm only contains gcc-toolchain) gives me gcc 11? <Rutherther>ieure: I have serious doubts this would be an upstream bug, since I am not able to find any reports about this <Rutherther>fanquake: yes. First time you specified using specifications, which searches for all packages with name gcc-toolchain, and gets the latest, being 14.2. Whereas in second case you pointed to guile symbol which is bound to gcc toolchain of version 11 <ieure>Rutherther, Okay. Can't promise anything, but if you file a bug with some reproduce steps, I'll take a look. <look>Rutherther: I had this problem for a couple months on zen-browser (a ff fork), it used to work having the native-messaging-hosts directory in '~/.zen', recently I gave another shot at debugging and moved it to '~/.mozilla' and it started working once again <look>Perhaps its something exclusive to zen-browser, but maybe it works for you as well <f5mg_firewalled>Alright, it looks like the issue is with my commits, not with `guix pull` - I created a test branch on master with a trivial commit, and that pulls just fine without huge rebuilds <Rutherther>look: I have tried both firefox and librewolf, with firefox I of course made native-messaging-hosts, so right now I have "~/.mozilla/native-messaging-hosts/com.github.browserpass.native.json". And it still doesn't work <Rutherther>it's really frustrating Firefox doesn't have a way to debug this. As I wanted to get down to seeing if the issue is in browser, or in the messaging host, I also tried Chromium, and at first I didn't get it right, because installing the extension from extracted directory apparently leads with different extension id. Chromium told me explicitely that this extension doesn't have it allowed, and then that there is an error in loading the file (which was... <Rutherther>... because of syntax error). Whereas Firefox just says: An unexpected error has occurred. :/ <look>Rutherther: I just tried passff on firefox and the same '~/.mozilla/native-messaging-hosts/passff.json', which works for me on zen-browser, does not work on firefox <look>Tried debugging, I get the same 'An unexpected error occurred' treatment :( <Rutherther>look: interesting. Well, maybe a time to try out this zen browser :) it looks kinda interesting <Rutherther>ieure: seems like librewolf in your channel is failing to build for me <df>am I right in thinking that parts of the build system code run even when installing substitutes? for example, it appears that pyproject-build-system always runs tests <ieure>df, It doesn't work like that to my knowledge. Do you have a paste of this behavior or a reproducer? <df>ieure: yes, I am currently failing to install python-pillow-heif due to a pair of test failures (I actually only want is as a dependency of another package but this happens even when I install it solo) <df>... although, actually it says the derivation will be *built*, even though I haven't enabled --fallback... <df>I'm not sure if that means it failed to find a derivation? <df>just getting the build log <ieure>df, That is building locally because no substitute is available. Which, since the build fails, is not surprising. <ieure>df, `guix weather python-pillow-heif' will tell you if substitutes are available. <df>ah, I didn't know you could run that on individual packages <df>and yes, now I look at the log more closely it is byte-compiling as well as testing <ieure>Yeah, package looks broken. If it can't be built, it can't have substitutes. Would recommend filing a bug on this, or figuring out what's wrong and sending a patch if you're inclined to. <df>so if I want to attempt to repro the build in a shell, is guix shell -D what I'm after? <ieure>df, Easiest thing here is `guix build -L python-pillow-heif', which will leave the build directory in whatever state it was when the failure happened, then cd into it, run `guix shell -D python-pillow-heif --pure', and poke around. <df>isn't the default for guix package to just fail if a substitute isn't available and --fallback isn't specified? <df>or is a substitute just not being available a different situation to a "Substitution failure" as described in the manual? <df>> Note that when substitutes are disabled or no substitute is available for the derivation in question, a local build will always be performed, regardless of whether or not --fallback was given. <df>my bad, should read more carefully <ieure>df, No, it's to build from source. <Agiel>Is there a way to write a shepherd service and make it start before another already existing one? <Agiel>Like for example create `my-service` and make it start _before_ `networking` <Agiel>Without editing `networking` <vhns>This is a stupid question, but, whenever using an offload setup, will guix respect `--no-substitute`? <vhns>I get the feeling that my offload server is just pulling binaries off of substitutes as I don't see any real load on it even building compilers such as gcc or llvm/clang <vhns>s/--no-substitute/--no-substitutes <cancername_>What are some common reasons for "guix home reconfigure" to be very slow? <PuercoPop>anyone running cuirass for their personal channel? How hard is it to setup? <ieure>PuercoPop, I am, it's pretty straightforward to set up. <cancername>not yet, but I would like to, so, looking for info :) <ieure>The only thing that was kind of annoying was getting the combination of Cuirass and substitute server working properly. <ieure>cancername, I couldn't find anything documented, so just had to mess around until it worked; it wasn't clear to me that I even needed a separate substitute service, because Cuirass also has one, and it kinda works, but is for sending stuff between builder machines, not for clients to use. <cancername>that does sound like the guix experience I've had so far :P <ieure>Will also say that I've run into some bugs and frustrating behavior with the setup. Like: the declarative config doesn't handle removing or renaming specifications. <ieure>So if you have (name "blah") and rename it to (name "blah-two"), you get a blah-two specification added, and blah remains. <ieure>It also is not great about communicating whether it's building or not, it'll say there are no active builds when it's chewing 100% of your CPU doing them; and when builds fail for non-package-related issues (like running out of disk space, or the OOM killer nuking your process), it can be annoying to get it to rebuild. <ieure>I have a different machine on the same net running nginx, so I have that doing the reverse proxying. It's managing a Let's Encrypt wildcard cert and I didn't want to put the Cuirass box under a different domain or have one special cert for it. <ieure>The magic is having all the nar paths go to the guix-publish-service type and everything else to Cuirass. <ieure>But I get the nice thing where `guix weather' shows me queued/active builds, build rate etc. Just like the official ones. <ieure>I just changed that setup to build aarch64-linux stuff with qemu. That's real slow. <cancername>I think it's time to write blog posts about how I did certain Guix stuff to make it more googleable <ieure>I'm not real sure if having separate specifications per architecture is a good idea or not. <ieure>vs. one spec for multiple architectures. <luca>Shouldn't most packages be cross compiled, not built with qemu? <ieure>cancername, You give Cuirass a list of specifications, each spec is some channels/packages to build, and what architectures to build for. <ieure>luca, I believe cross compilation support is a lot newer and not as reliable as using the native stuff in an emulator. <cancername>ieure: right. can I not make it use my Guix channel? <PuercoPop>ieure: do you have the configuration of your service available online? <meaty>Is there a way to tell 'guix build' to list only the store dir of a certain output of a package? <meaty>'guix build sdl2:out' doesn't work <meaty>true, was just wondering if there was a better way