IRC channel logs
2026-06-10.log
back to list of logs
<meato>is anyone around to help with a qt packaging thing <meato>I'm trying to package qalculate-qt, but it seems the builder keeps looking for lrelease in the qtbase store prefix for some reason, instead of qttools where it actually is <untrusem>meato: can you share the log in the pastebin <meato>I tried substitute*ing in an LRELEASE=[correct path] line into the .pro file, but it didn't help <meato>word, the debian pastezone doesn't like store paths :p <untrusem>hmm i will need no open my thinkupad now :p <untrusem>see other package definition on how do they do substitution <meato>anyways, i get the same error when I don't substitute at all <ieure>meato, Are you cross-compiling or anything like that? <meato>it's now 'lambda _' since i'm not using any inputs (yet) <meato>i know there's a more 'correct' way to do it but i'm not worrying about that for now <ieure>meato, You should use (lambda* (#:keys inputs #:allow-other-keys) ...) and for qttools, (search-input-file inputs "bin/lrelease") <ieure>#$qttools uses the imported qttools, not the one in the package's inputs, and if some package variant replaces qttools, the build will break. <ieure>meato, Try building with -K and looking at qalculate-qt.pro to see what your substitute* is doing. I agree it's odd that the path in the error is for qtbase when you're specifying qttools. <meato>ieure, i made those corrections and verified that the substitute does what i mean it to do <ieure>meato, Has to be something else qmake is doing, then. <ieure>meato, You can `guix shell -D qalculate-qt' and then cd into the failed build dir, source the environment file, and run commands yourself. <ieure>Lot faster to debug this way than building over and over. <ieure>You can also add `display' calls in your build steps if you want to debug what's happening inside the build process. <meato>thank you, i'm in a -D environment now <meato>the error happens when 'qmake' is run, and setting the LRELEASE env var doesn't change anything... <dcunit3d>is there a quick way to figure out which modules to import when symbols are undefined? <dcunit3d>i'm cleaning a bunch of stuff up and it's several layers of accumulated code with broken references <dcunit3d>i'm thinking for now i should set up a watch or watchexec to compile files as I change them and just keep an eye on that <ekaitz>sham1: you are now a guix developer, forever in the history! <loquatdev>Hello. I'm messing around with the linux kernel. Is there a recommended guix shell for kernel hacking? I could just customize a package but I'd like to mess around with menuconfig and the like to test a few things. <identity>loquatdev: ‹guix shell -D linux-libre› is probably a good start <csantosb>Hi Guix ! I'm getting crazy with this clang closure problem !9101; the only output with refs to the store is `bin/yosys-config`, which I delete <csantosb>I still get 2548.5 MiB of closure size for this package. What the ? <ieure>> the only output with refs to the store is `bin/yosys-config` <ieure>I would be very surprised if this was the case. <ieure>If you run `find $(guix build yosys) -type f -print0 | xargs -0 strings | grep /gnu/store`, you get no output at all? <ieure>You can see from your `guix size' output that a reference to LLVM is the main culprit here, since it's 2.2gb. <csantosb>`find $(guix build yosys) -type f -print0 | xargs -0 strings | grep /gnu/store/5j3jchmpy9gqcrr3ap7n0mrh7m37zr6i-yosys-0.66-0.d709374` <ieure>Seems like the same problem as before, no? You have some store references in output which are bloating the closure size; you need to figure out what's including them and if they're necessary. <csantosb>Nothing at all. Still total: 2538.0 MiB. <ieure>csantosb, Why did you change the grep argument to only look for that one store items, instead of the one I gave, which will print *all* referenced store items? <csantosb>I'm searching only inside of the package. <ieure>Yep, and you can see multiple references to build tooling like clang in that output, which means clang is part of the package closure, which is why it's now >2gb heavier. <ieure>The problem and solution are still the same, you need to figure out *why* those references are ending up in the build; whether they're necessary for the correct functioning of the program; and if not, how to adjust the build to not include them. <csantosb>Sure. The question is where to look at ? Inside the output itself there is no /gnu/store whatsoever. <csantosb>Which is how Guix builds the package closure, IIUC. <ieure>csantosb, The output of the command disproves that, every line in your paste is a store path in your package output. <ieure>csantosb, `grep -r $(guix build yosys) lvwvkmkv5lszgi8i5svj5jf5bgbxg2zf' will tell you all the files in the package's output which reference clang. <ieure>csantosb, Maybe your mental model of this is still off? Any file in the output containing a store path is a store reference which increases the closure size. Not just if they're in a binary. If the LICENSE file has a store path, that item is added to the package closure. <csantosb>Got it, thanks ieure; the `bin/yosys` binary itself includes a suspicious string with the full clang++ path <csantosb>You're right about the mental model: it is not obvious that a comment string in a trailing useless text file depth the package hierarchy pulls GB to the closure size. <ieure>Yeah, it is odd when you first encounter it. But Guix has no way of knowing the context of a particular store reference, so all references increase the closure size. <ieure>csantosb, Based on your paste, it also looks like some build tooling is leaking into the output, I see what seems like a bunch of CFLAGS type stuff and paths to compilers. I have no idea what yosys is or how it works, but that sort of thing is unusual, thus is suspect. <csantosb>I'll investigate that, now that I know where to look at <ieure>csantosb, Do you understand what the find command I gave you does? Would it be helpful to hear an explanation of what it does? <csantosb>No, its ok; I prefer that to accept 2 extra GB everytime I build with clang (in EDA, it is preferred) <csantosb>Now, this maybe explains the overweight of most packages, which is good and bad at the same time. <csantosb>There is a large marge for improvement, I mean. <ieure>A big part of it is that Guix doesn't split up packages like Debian does, so you get a larger package when all you actually need is the one .so file inside it. <ieure>There are valid arguments for and against splitting up that way, but that's certainly one of the things driving it. <yelninei>One of the problems is that you cannot have circular references between outputs, and then there is the issue with grafts <yelninei>and things keeping references when they should not <ieure>Yes, it's semi-common for that kind of build metadata to cause this issue. <ieure>Looks easy to address. Though I do see multiple references to clang in your paste, so there may be other places embedding it as well. <csantosb>The thing is, we don't have much documentation about this kind of topics, which turn out to be really relevant <csantosb>Say a ci pipeline somewhere: every time you trigger it, you need to download tones of GB for nothing. <ieure>Yes, Guix could do much better in terms of disk/network efficiency. Particularly in the installer, I think it's a poor experience to install the OS over the network, then have the very first update redownload most of what you just spent 45m downloading. <ieure>These days, I always install a minimal system, just enough to log into a console and update, then pull down the stuff I need. <ieure>But this isn't something a new user is going to know or be able to do. <csantosb>"References are a subset of the inputs of the derivation; this subset is automatically computed by the build daemon by scanning all the files in the outputs" in "8.10 Derivations", is the only relevant info I could find. <csantosb>Thanks again ieure, I'll try to complete the doc somehow. <ieure>csantosb, I honestly think it might be useful to take all the dev-related stuff and put it in a separate manual specifically for Guix internals and development. <dajole>Today an update caused my external monitors to no longer work, and it's so nice to just be able to `guix pull --roll-back` and then reconfigure and things are working as before :) <ieure>I've only needed it rarely, but it is so so so nice to have when you do need it. I also appreciate how I have never once ended up with a broken system due to dependency issues after upgrading, which happens a good bit with Debian (worst when upgrading from one release to another). <orahcio>Hi, How to send fixes to very old PR? <ieure>orahcio, Did you open it or did someone else? <ieure>orahcio, You have two options. One, make a PR and set the other PR branch as your target. Someone would then have to merge your PR into the initial one, then merge that. <ieure>Two, open a new PR which combines the initial PR and your fixes, and reference the original PR in yours. Someone would then have to close the older one and merge yours. <orahcio>ieure: #9227, I think it is the option two. <simendsjo>I notice docker is at v20, which was eol 2023. I guess there are good reasons, but it looks like it's so old I cannot run e.g. nextcloud. <ieure>simendsjo, Yes, I'm not sure what exactly the deal is, but there are issues with newer versions. In the mean time, you can use podman instead, or run containers directly managed by Guix using the OCI container service type. <simendsjo>ieure: Not sure podman works. At least it looked problematic given the issues I found. I can try the OCI container service as I haven't tested that yet -- I just write shepherd services starting docker/docker-compose. <ieure>simendsjo, I use Podman regularly, it works fine. <simendsjo>ieure: "This is a thin wrapper around Docker’s or Podman’s CLI that executes OCI images backed processes as Shepherd Services." <- not sure oci-service would work either. <ieure>What issues did you find with podman? <simendsjo>ieure: Yes, I use podman for things too, but in the context of nextcloud there was some issues. But I'll give it a try. <ieure>Mm. I haven't run Nextcloud under Podman, but it is definitely on the complex side to operate, if you want to do it correctly (with redis, a DB, and a container to run jobs). <simendsjo>ieure: Ah, it seems the all-in-one container thing controls docker itself, so that cannot be used. At least it expose the docker socket, so I guess it's because it has some magic to start and configure other containers. <ieure>simendsjo, I personally would never grant any third-party container the ability to control Docker itself. Hugely risky thing to do. <ieure>simendsjo, That org puts out a bunch of stuff, I always use the official containers, though. <ieure>simendsjo, I would personally recommend that you set up the separate containers, Nextcloud has an example compose file you can use, podman has podman compose that it ought to work with. <simendsjo>ieure: Thanks, I'll look into it. I would like to try it a bit before investing a lot of time into configuring and maintaining it. <ieure>simendsjo, I've been selfhosting it for, I'm not even sure how long now. 5+ years at least. Happy to answer questions if you've got them. <ste5e>I used to use nextcloud:fpm with reasonable success on Guix. It's doable. <simendsjo>ieure: Nice! You're running it on docker, but not on Guix? And do you have any additional tools installed? What is the maintenance/upgrade path like? I don't want to give myself a lot of extra work, but I *do* like that it looks like I can replace pretty much every service I use. <ieure>simendsjo, Yes, I run Debian on my more server-oriented hardware, mainly because it has ZFS support. <ieure>simendsjo, I have numerous plugins, Nextcloud News is the one I use the most, probably more than Files. There's a package that lets elfeed sync feeds/items/read/starred states with it, I use it allll the time. <untrusem>ieure: did you take a loot at my librewolf pr? <ieure>untrusem, No, didn't see it. I'll look after work today. <ieure>simendsjo, Upgrade path is *usually* pretty painless, but they only support upgrading from the previous major version. So 28.x -> 29.x -> 30.x is fine; 28.x -> 30.x will not work, it prints an error and refuses to proceed. <ieure>simendsjo, I pin to the major version in my compose file, when I want to upgrade, I bump to the most recent point release of the major version, increment the pinned version, pull and `docker compose up -d --build'. <ieure>simendsjo, The upgrade process is automatic and triggered by the container starting up. There's also a system report feature in the admin dashboard which will check your installation and point out things that should be fixed. Between those two, it's been pretty smooth sailing. <ieure>simendsjo, The stuff that's kind of aggravating is when they require changes to the compose setup itself, or to the nginx vhost config. The nature of both those things is that you're not using their configs verbatim, so you have to diff your working config vs. their example one to see what all you need to pull in. That's happened maybe once or twice across those 5+ years. <ieure>simendsjo, Yes, my whole config is in Git as well. <ieure>But I don't have a good workflow for, effectively, rebasing my changes on top of a file that isn't and never will be under SCM. <simendsjo>ieure: This is why I haven't made any changes to the file at all. All changes is made with the guile script. Not ideal either of course... <ieure>simendsjo, Well, Nextcloud is much easier to selfhost than Immich, if that's any comfort. I run both.