Hi Guixers,
First let me say I'm a Maven novice, so it's possible I'm doing something
dumb on the Maven side of things.
I'm unable to make a bare-bones Maven project build in Guix.
This looks to be a problem with mismatched dependencies in Guix around
java-commons-codec.
I suggest what probably
Hi all,
The issue also exists when using --with-commit - see below for a refined
test that makes it trivial to demonstrate with any package where the source
is retrieved from git.
On Tue, 18 Jan 2022 at 10:10, Phil wrote:
>
> > Philip Beadling writes:
>
> >No, and we probably should do, even
Hi Ricardo, all,
I think we’ve worked out what the issue is, and have a proposed workaround,
and perhaps a case for solving the problem in Guix itself (depending on
what you people think!).
The issue is that despite each build being performed in its own isolated
container, these containers ar
Hi all,
Was wondering if anyone had come across the issue with mypy using modular
stubs in v910. As far as I can see installing for example
python-types-requests and python-mypy in Guix leads to mypy ignoring the
supplemented request stubs provided by the types-requests package. I've
raised this
I was able to write a short manifest that avoided the overwriting of the
original "foobarpy" package in my case, and instead cleanly replace it with
a newer version specified using "with-source".
By setting, for example, GUIX_FOOBAR_VERSION=1.23 and
GUIX_TEST_PACKAGE=my-package - I can now create
Hi all,
I'm using the following incantation:
guix build
--with-source=foobar@9.5.0=/opt/thirdparty/foobar/foobar950_beta/linux64
<--with-source=gurobipy@9.5.0=/opt/thirdparty/gurobi/gurobi950_beta/linux64>
foobar
However the package build is failing with:
(copy-file "lib/libfoobar.so.9.0.1" "/
