On Sun, Dec 22, 2024 at 12:06:23PM +0100, Gabor Gero via wrote:
> Hello,
>
>
> The problem is that if I try to build it via guix build, while all the Rust
> dependencies get pulled in by guix perfectly fine, once it reaches the build
> stage, cargo prints the following warning:
> "warning:
>
On Sun, Dec 22, 2024 at 12:06:23PM +0100, Gabor Gero via wrote:
> Hello,
>
>
> The problem is that if I try to build it via guix build, while all the Rust
> dependencies get pulled in by guix perfectly fine, once it reaches the build
> stage, cargo prints the following warning:
> "warning:
>
Simon Josefsson via writes:
> I didn't test now but I think Debian images handle all three entrypoint
> values, but the 'guix pack' image doesn't.
That was not true! Here the situation:
https://gitlab.com/debdistutils/guix/container/-/pipelines/1600726433
Debian fails on these two GitLab .git
Simon Josefsson via writes:
>>> Re /etc=etc it seems GitLab's docker setup bind-mounts things below
>>> /etc/ and it cannot handle the root /etc symlink. A workaround is to
>>> use `lndir` which I use in the `test-amd64-package-install` job. This
>>> is limitation of GitLab's docker setup: I tr
On Sun, Dec 22, 2024, at 01:12, Marek Paśnikowski wrote:
> This is exactly it. You always must supply the #:import-path in Go build
> system.
>
> This path is vital to the operation of the build system, as it adapts Go
> build
> environment to Guix environment. This path matches the name of th
>
> > Hello,
>
> > I am trying to build the `guix` package on Fedora Asahi Remix 41 (aarch64)
> > using `guix build --verbosity=3 guix` and `guix home reconfigure` and in
> > both instances the build has been failing. This has been an issue for
> > around a week despite running
> > `guix pull`
