'man mkfs.ext4' fails on aarch64 when cross-compiled from x86_64. It is
unable to execute 'gzip'. file /gnu/store/...-gzip-1.10/bin/gzip' shows
it is for x86_64.
It also links to the wrong bzip2 and xz.
--
Efraim Flashner אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D
Hi,
Marius Bakke skribis:
> On the 'core-updates' branch, using copy-recursively on a nonexistent
> directory does not cause a build failure. Instead an error is printed
> and the script continues:
>
> (copy-recursively "doesnotexist" output)
> [...]
> starting phase `install'
> i/o err
I try to read and understand how wrap-qt-program in qt-utils.scm works.
When building QT program, Guix builder populates qt related environment
variable, and wrap-qt-program just record it into wrapper.
However, the wrap behaviour in qt-build-system is quite different, it
search all inputs and ma
Hi Jérémy,
Jérémy Korwin-Zmijowski skribis:
> I made some more attempts. I was unable to reproduce the previous
> scenario… Looks like with my ssh connections I put myself in an
> exceptionnal situation.
>
> All I got is `guix deploy` running forever (I let it more than 2 hours)
>
>$ guix de
Hi,
On my system, guix system reconfigure stopped running since commit:
6a060ff27ff68384d7c90076baa36c349fff689d.
The last good commit was its parent:
dea1ee1fd740248307f74ca4cb70b94742264098
Regards,
Yasu
~$ sudo guix system reconfigure ~/config.scm
The following derivations will be built:
Hey Ludo' !
Thank you for asking !
I apologize to have not taken the time to investigate on this
(understand: put 'pk' commands everywhere haha. I don't know what else
to do).
Just did a retry. The command line still hangs with :
$ guix deploy ynm-droplet-declaration.scm
La (1) machine s
Hi,
Jonathan Brielmaier skribis:
> there seems to be another regression in this series.
>
> Pulling from 6a060ff27ff68384d7c90076baa36c349fff689d gives:
> ```
> [ 1/20] Loading './guix/base32.scm'...
[...]
> [10/20] Loading './guix/store/deduplication.scm'...
>
> ;;; Failed to autoload copy-fi
Hi Mark, and who may be interested,
On +2020-12-14 19:11:51 -0500, Mark H Weaver wrote:
> reopen 45109
> thanks
>
> Earlier, I wrote:
> > I initially tried Marius's idea to revert the dconf update, which
> > seemed to work, but now I find that I'm unable to reproduce the
> > problem, even with my
Hi!
If you do, as a regular user:
guix pull
sudo guix system reconfigure …
the ‘guix system reconfigure’, as part of the downgrade-detection
machinery, triggers an update of the channel checkout(s) in
~root/.cache, even though ~USER/.cache is already up-to-date.
One way to avoid it might be
This issue is solved by the new importer.
--
Regards
Hartmut Goebel
| Hartmut Goebel | h.goe...@crazy-compilers.com |
| www.crazy-compilers.com | compilers which you thought are impossible |
Hello,
We already have `--with-branch=`, `with-commit=`, ... An additional
option could be `--with-patch=package=add-extra-feature.patch` which
would apply the patch file `add-extra-feature.patch` located in the my
current directory to the sources of `package` before Guix starts
building `package`
Ludovic Courtès writes:
> Marius Bakke skribis:
>
>> On the 'core-updates' branch, using copy-recursively on a nonexistent
>> directory does not cause a build failure. Instead an error is printed
>> and the script continues:
>>
>> (copy-recursively "doesnotexist" output)
>> [...]
>> start
Dear,
Using Guix f4450e8, the package emacs-next builds:
$ guix build emacs-next
/gnu/store/93hb0g731f64avayj8rdz26bz48xg2ri-emacs-next-28.0.50-0.2ea3466
and the recipe reads:
--8<---cut here---start->8---
(define-public emacs-next
(let ((commit "2ea346
Hi,
On Thu, 17 Dec 2020 at 12:03, Ludovic Courtès wrote:
> Marius Bakke skribis:
>
>> On the 'core-updates' branch, using copy-recursively on a nonexistent
>> directory does not cause a build failure. Instead an error is printed
>> and the script continues:
>>
>> (copy-recursively "doesnotexi
14 matches
Mail list logo
