Hi Jesse,
On Mon, 02 Sep 2019 20:07:53 -0600
Jesse Gibbons wrote:
> On Mon, 2019-09-02 at 22:49 +0200, Danny Milosavljevic wrote:
> > Hi,
> >
> > On Mon, 02 Sep 2019 12:52:49 -0600
> > Jesse Gibbons wrote:
> >
> If the bootloader build fails, which appears necessary to generate the
> list,
> Where does guix get this list? Is it configured or automatically
> generated?
It's all the filenames suffixed with "_defconfig" in the "configs"
subdirectory of the u-boot source, minus the suffix.
- reepca
On Mon, 2019-09-02 at 22:49 +0200, Danny Milosavljevic wrote:
> Hi,
>
> On Mon, 02 Sep 2019 12:52:49 -0600
> Jesse Gibbons wrote:
>
> > guix tries to build an entire system. It doesn't look like it
> > checks if
> > "dne-board" is a valid board until it is building the image. It
> > takes
> > ho
Hi,
On Mon, 02 Sep 2019 12:52:49 -0600
Jesse Gibbons wrote:
> guix tries to build an entire system. It doesn't look like it checks if
> "dne-board" is a valid board until it is building the image. It takes
> hours to cross-compile the kernel, and even longer if the kernel needs
> to be deblobbed
There should be a faster way to list the supported boards with custom
versions of U-Boot.
>From manual:
Many ARM boards require a specific variant of the U-Boot
(https://www.denx.de/wiki/U-Boot/) bootloader.
If you build a disk image and the bootloader is not available
otherwise (on anot
The saga continues!
With today’s commit, the execution time of
guix build -e '(@ (gnu packages emacs) emacs)' -d
is down from 1.54s to 1.08s on my 2.6 GHz laptop. That’s 30%. :-)
The head of the profile is now like this:
--8<---cut here---start->8---
sch
Nikita Karetnikov skribis:
> While we are at it, will it be better to rewrite 'fold-packages' and
> similar things (like 'search') using streams?
Good question.
[...]
> 'time' shows that the above is a bit slower than the current version.
> Will it b
am
(module-map (lambda (sym var)
(false-if-exception (variable-ref var)))
module
init
(list->stream (package-modules
'time' shows that the above is a bit slower than the current version.
Will
l...@gnu.org (Ludovic Courtès) skribis:
> No, but it’s true that it’s surprisingly slow to start:
>
> $ time ./pre-inst-env guix-package
>
> real0m1.084s
> user0m0.904s
> sys 0m0.058s
This is actually the time it takes to connect to the daemon, and to
compute the derivation of Guile (
your definition of fast. A second, I would say, which
> felt slow given that it was only a symlink. Maybe this was just the time
> for starting guix-package; did it become faster?
No, but it’s true that it’s surprisingly slow to start:
--8<---cut here---start
ich
felt slow given that it was only a symlink. Maybe this was just the time
for starting guix-package; did it become faster?
Andreas
Andreas Enge skribis:
> Am Mittwoch, 30. Januar 2013 schrieb Ludovic Courtès:
>> C’m’on, this one was already fast, because all it does is to create a
>> symlink.
>
> That is why I wondered. But when I rolled back 20 generations the other
> day, it did not feel fast at all.
Really? That’s weir
Am Mittwoch, 30. Januar 2013 schrieb Ludovic Courtès:
> C’m’on, this one was already fast, because all it does is to create a
> symlink.
That is why I wondered. But when I rolled back 20 generations the other
day, it did not feel fast at all.
Andreas
4
times as fast as 3 days ago. :-)
> Excellent! Is "guix-package --roll-back" also faster now? It feels so!
C’m’on, this one was already fast, because all it does is to create a
symlink.
Ludo’.
Am Mittwoch, 30. Januar 2013 schrieb Ludovic Courtès:
> With commits a7b6ffe and bdcf35a, you should notice that ‘guix-build’
> and similar are more than twice as fast as two days ago.
Excellent! Is "guix-package --roll-back" also faster now? It feels so!
Andreas
Hello!
With commits a7b6ffe and bdcf35a, you should notice that ‘guix-build’
and similar are more than twice as fast as two days ago.
This was achieved by adding caches in the now obvious places, which
noticeably reduces the number of round trips and the amount of data sent
to the daemon.
Ludo’.
16 matches
Mail list logo
