Ricardo Wurmus writes:
> pre-inst-env modifies the GUILE_LOAD_PATH to put the Guix modules from
> the current directory first. It does not, however, arrange for all
> dependencies to be placed on GUILE_LOAD_PATH.
>
> You are still expected to run pre-inst-env in an environment containing
> all of
Hi Damien,
On Sat, 29 Feb 2020 at 16:01, Damien Cassou wrote:
> $ guix describe
> Generation 13 Feb 29 2020 15:00:51(current)
> guix f76c16d
> repository URL: file:///home/cassou/Documents/projects/guix/guix
> branch: master
> commit: f76c16d220e6c349441c08bf25a5197037490fa5
zimoun writes:
> I suppose that the Git repo is at the commit f76c16d, right?
yes
> The first test to fail is 'tests/lint.scm', right?
> And is there only 2 failing tests?
yes. And the log files for those are attached to my initial email.
--
Damien Cassou
"Success is the ability to go from
Hi Damien,
To ease the debugging processing, you should not run '-j4'.
I have tried:
--8<---cut here---start->8---
cd /tmp/
git clone https://git.savannah.gnu.org/git/guix.git
git checkout -b test f76c16d
guix time-machine --commit=f76c16d -- environment --pu
Dear,
It is not a bug so closing.
Feel free to ask more details on help-g...@gnu.org.
All the best,
simon
Dear,
On Sun, 1 Mar 2020 at 04:11, Michael Gorlick
wrote:
> guix substitute: error: download from
> 'https://ci.guix.gnu.org/nar/gzip/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash'
> failed: 502, "Bad Gateway"
> @ substituter-failed /gnu/store/mzfkrxd4w8vqrmyrx169wj8wyw7r8i37-bash 256
> fetching path
Build log extract:
--8<---cut here---start->8---
==
ERROR: orator.commands.migrations (unittest.loader._FailedTest)
--
ImportE
Marius Bakke writes:
> Hello,
>
> There is a strange bug on the core-updates branch: if you 'guix pull
> --branch=core-updates', everything from around 'guile-bootstrap@2.0' in
> the package graph will have different derivations from what you get in
> the git checkout:
>
> On my local fork of cor
Even after upgrading to v3.2b2, I still got:
--8<---cut here---start->8---
starting phase `check'
Build log extract:
--8<---cut here---start->8---
OS_STDERR_CAPTURE=${OS_STDERR_CAPTURE:-1} \
OS_TEST_TIMEOUT=${OS_TEST_TIMEOUT:-60} \
${PYTHON:-python} -m subunit.run discover -t ./ . --load-list
/tmp/guix-build-python-hacking-1.0.0.drv-0/tmp0b3_dkul
running=O
Build log extract:
--8<---cut here---start->8---
starting phase `check'
running "python setup.py" with command "test" and parameters ()
running test
running egg_info
writing anndata.egg-info/PKG-INFO
writing dependency_links to anndata.egg-info/dependency_links.
Marius Bakke writes:
> Marius Bakke writes:
>
>> Hello,
>>
>> There is a strange bug on the core-updates branch: if you 'guix pull
>> --branch=core-updates', everything from around 'guile-bootstrap@2.0' in
>> the package graph will have different derivations from what you get in
>> the git check
Hi Mathieu,
Mathieu Othacehe writes:
> So if it's ok for you, I'll try to implement a GCC hack so that we can
> keep using C_INCLUDE_PATH on core-updates and have QEMU building, as you
> proposed.
Did you get anywhere with this? As Ludovic mentioned, it might make
sense to work around it in gn
Hello,
Currently 'linux-libre' fails to build on armhf-linux due to a
segmentation fault in GCC:
--8<---cut here---start->8---
CC [M] drivers/net/wireless/broadcom/b43/radio_2057.o
*** WARNING *** there are active plugins, do not report this as a bug unless
Hi Marius,
Marius Bakke writes:
> Marius Bakke writes:
>
>>
>> I've tracked this down to 'gash-boot'. Namely the use of ,(version): it
>> evaluates to '2.2.6' when run with ./pre-inst-env and "3.0.0" after
>> 'guix pull'.
>>
>> I suspect both are wrong, and that it really intends to use the ve
Hey Marius,
> Did you get anywhere with this? As Ludovic mentioned, it might make
> sense to work around it in gnu-build-system too if patching GCC turns
> out to be difficult.
Yup, turned out patching GCC was too difficult. I'm experimenting a
filter over inputs passed to set-path-environment
16 matches
Mail list logo
