Identifying cause of local package build

Identifying cause of local package build

[Skyler via]

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

Re: Identifying cause of local package build

[Felix Lechner via]

Hi Skyler,

On Mon, May 1, 2023 at 5:19 AM Skyler via <help-guix@gnu.org> 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

Re: Identifying cause of local package build

[Simon Tournier]

Hi,

On Fri, 28 Apr 2023 at 21:33, Skyler via <help-guix@gnu.org> 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

[Skyler]

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

[Skyler Ferris via]

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

[Simon Tournier]

Hi,

On mer., 24 mai 2023 at 20:56, Skyler Ferris via <help-guix@gnu.org> 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

[Eugen Stan]

[-- Attachment #1: Type: text/plain, Size: 982 bytes --]

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 <help-guix@gnu.org> 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

[-- Attachment #2: eugen_stan.vcf --]
[-- Type: text/vcard, Size: 181 bytes --]

begin:vcard
fn:Eugen Stan
n:Stan;Eugen
email;internet:eugen.stan@netdava.com
tel;cell:+40720898747
x-mozilla-html:FALSE
url:https://www.netdava.com
version:2.1
end:vcard