Re: Identifying cause of local package build
Hi, I would also check the size of /tmp partition. I build of iced-tea / openjdk was failing because it was running out of disk on /tmp. guix-daemon builds packages in /tmp . Some packages need a lot of disk to build. In my case I had to increase /tmp to 7.5 GB until the build passed. This was visible in the error log and the same issues was happening on substitute servers (build was failing with this issue). Regards, Eugen On 25.05.2023 21:31, Simon Tournier wrote: Hi, On mer., 24 mai 2023 at 20:56, Skyler Ferris via wrote: the packages in my system configuration into a manifest and ran `guix weather` against it, and it said that only 85% of packages have substitutes available. I had assumed that substitutes should be available Yeah, some process requires some improvements. Hopefully, the CI and tooling is improving daily. :-) Cheers, simon -- Eugen Stan +40770 941 271 / https://www.netdava.com begin:vcard fn:Eugen Stan n:Stan;Eugen email;internet:eugen.s...@netdava.com tel;cell:+40720898747 x-mozilla-html:FALSE url:https://www.netdava.com version:2.1 end:vcard
Re: Identifying cause of local package build
Hi, On mer., 24 mai 2023 at 20:56, Skyler Ferris via wrote: > the packages in my system configuration into a manifest and ran `guix weather` > against it, and it said that only 85% of packages have substitutes available. > I had assumed that substitutes should be available Yeah, some process requires some improvements. Hopefully, the CI and tooling is improving daily. :-) Cheers, simon
Re: Identifying cause of local package build
I believe I understand what is happening now, and it is the result of the way guix releases software and not a bug in my configuration. I put all of the packages in my system configuration into a manifest and ran `guix weather` against it, and it said that only 85% of packages have substitutes available. I had assumed that substitutes should be available and either there was something in my configuration that was causing me to download an old version of a package, which had presumably been deleted from the server, or that I was telling it to build some unexpected variant. But thinking about it more, updating a guix system is just pulling down package definitions, which become available before the substitute server finishes building everything. And it has a lot to build. So I think this is just expected, and guix decides to build the software locally instead of just refusing to let me upgrade. I could probably configure the system to use a commit from a short time ago which still has substitutes available, but I have been meaning to minimize my system anyway since I don't use much beyond a terminal in guix. And this means I will remove most of the packages that take a long time to build, and the remaining long-build packages are things like the kernel which do have substitutes available. Sincerely, Skyler
Re: Identifying cause of local package build
Thank you for the replies! The `guix refresh --list-transitive` command was helpful for what I was trying to do, although I now think I was going down the wrong path. While checking things in my system, I noticed that the guix command that was invoked under a root shell pointed to a different binary than under my user's shell. I assumed that having different versions of guix simultaneously operating on the same store could cause lots of problems which are difficult to explain, so I decided to reinstall the system from scratch, which did not seem too troublesome since guix's commitment to declarative configuration makes re-installation very easy. I had some issues where I saw error messages similar to https://issues.guix.gnu.org/56005, which was speculated to be due to difficulties communicating with the server. So I just waited a few days each time this happened and re-tried, and eventually I got the bare-bones config from the installer ISO to install to my machine. However, I am still seeing a similar problem to before, when I try to `guix home reconfigure` the process starts building git-minimal. I stopped it immediately instead of waiting to see how far it got because this seemed to be the same behavior. I also found that `guix repl` produces an error that the __libc_pthread_init symbol is undefined in libpthread.so, although readelf tells me that the symbol exists. The symbol value is null which seems weird but I don't spend a lot of time looking at readelf output and every symbol in the '.rela.plt' section has a null value, so maybe this is expected. The error occurs if I run guile without any arguments, from the guile-wrapper used by guix. Running the system guile command works fine. Also, the error only occurs in the guix from `~/.config/guix/current/bin/guix`. This runs by default because it is in my path first, but if I run `/run/current-system/profile/bin/guix repl` then the program executes without issue. I'm not sure if the one in /run is an older version that I shouldn't use or if it's the one that I should be getting when I run plain guix (without a path). IIUC, `guix pull` is supposed to update the files in `~/.config/guix/current` to be the correct ones, and the guile-wrapper is pointing to an absolute path of libpthread in the store as it should, so I'm not sure how this error is occurring. The system has not changed much from the bare-bones config, I just added tmux, vim, and nss-certs to make the TTY easier to use and make sure I could download https urls. This seems strange. I'm going to keep looking into this, but hoping that something above might sound familiar to someone.
Re: Identifying cause of local package build
Hi, On Fri, 28 Apr 2023 at 21:33, Skyler via wrote: > Is there an efficient way to track down what is causing this inkscape > to be built, aside from manually running `guix gc --referrers` on > every derivation until I (hopefully) find something that leads me to > the root cause? The list of packages that can trigger a rebuild of inkscape are provided by: --8<---cut here---start->8--- $ guix refresh --list-transitive inkscape inkscape@1.2.1 depends on the following 349 packages: … --8<---cut here---end--->8--- Or you can also run something like, $ guix graph inkscape | grep label | cut -f2 -d'=' | cut -f1 -d',' to list the dependencies of inkscape. Is it what you are looking for? Cheers, simon
Re: Identifying cause of local package build
Hi Skyler, On Mon, May 1, 2023 at 5:19 AM Skyler via wrote: > > The only thing that requires this variant of inkscape is dblatex. I believe your issue arises elsewhere—either with a different variant of dblatex that is not requested via your use of 'guix shell', or a completely different package. Sorry I cannot help more. I am new to Guix and unfamiliar with most of the advanced tooling. Kind regards Felix
Identifying cause of local package build
Hello, Recently (since at least this past weekend) when I try to `guix system reconfigure` or `guix home reconfigure`, my machine tries to do a local build of inkscape and ends up failing (I suspect this is due to low resources available on my machine as the log simply says that it was killed by a signal, but I did not see any compiler errors). My guix config is a little complicated (although I only have one custom package, and it is a vim extension which declares no inputs) so I am trying to track down the reason for this build. I do not have inkscape explicitly installed, so there must be something that depends on it. When I try `guix shell inkscape`, a substitute is downloaded successfully. So I assume that there is some inkscape variant that is needed somewhere. I tried to find the reason for this with the following: ``` > guix gc --referrers > /gnu/store/j2g2vwf3h1r0pn0l6y95qr4lis5y03h9-inkscape-1.2.1.drv /gnu/store/009i7sq1df9q05i7hfk07axphabnsgrw-dblatex-0.3.12.drv /gnu/store/7w4i4ss6c3bncav8gq87bs3x4c8lrvi9-dblatex-0.3.12.drv /gnu/store/z4gr7lzsxis1yxr5sgxxfb8rpgp57fxd-dblatex-0.3.12.drv/gnu/store/zfk84536nvnpp4f2q2gz51wmb98ik2h4-dblatex-0.3.12.drv ``` The only thing that requires this variant of inkscape is dblatex. But `guix shell dblatex` also succeeds with only substitute downloads. I checked ci.guix.gnu.org and the most recent inkscape build on master for my architecture succeeded (http://ci.guix.gnu.org/build/369838/details), but this build ran 3 months ago. I tried searching for the derivation hash j2g2vwf3h1r0pn0l6y95qr4lis5y03h9 and got no results, but I think that this might not be an expected use of the search bar. I also tried deleting the ~/.cache/guix directory and pulling again, but this resulted in the same behavior. Is there an efficient way to track down what is causing this inkscape to be built, aside from manually running `guix gc --referrers` on every derivation until I (hopefully) find something that leads me to the root cause? My system is: ``` Generation 38 Apr 28 2023 14:23:04 (current) guix 4884ee6 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 4884ee6dd4b1694a4a502dd8058d6c61fa0c0199 ``` Thanks, Skyler
